JP2000227879A - Team data list management device, team data list storage device, team data list processing system, and their recording media - Google Patents

Abstract

(57) [Summary] [Problem] To provide a team data list processing system in which members in a group can manage a team data list and prevent unauthorized change of the list. SOLUTION: A member list 33 stores information on members constituting a team, and a team master list 34 stores information on persons who have authority to change both lists (that is, team data lists). The list storage function 36 is the storage device 32
Send and receive team data lists with The authority confirmation function 35 performs authentication and authority confirmation at the time of a reference request of the member list 33, and confirms whether the team data list should be transferred to the team data list management device 30. The list creator confirmation function 37 acquires the team data list and confirms whether or not the list has been created by a person having management authority. List change function 38
Adds, deletes, and modifies the team data list. The electronic signature function 39 acquires the secret key corresponding to the public key, and adds the signature of the list changer to the changed team data list.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to sharing various information and various functions provided to users between members (users or members) of a team corresponding to an organizational unit such as a department or section of a company. Create and manage team data lists
The present invention relates to a team data list processing system for storing and thereby safely sharing such information and functions among users for each team. More specifically,
The present invention relates to a system including a team data list storage device that performs processing related to storage of a team data list, and a team data list management device that performs various managements on a team data list acquired from the team data list storage device.

[0002]

2. Description of the Related Art In order to share various resources such as various kinds of information and functions provided to users among a plurality of users, a user requesting access to these resources has a right to truly access the resources. It is necessary to prepare a function to verify whether or not it has. In order to perform such verification, conventionally, a list called an access control list (hereinafter, abbreviated as “ACL”) in which users who have been granted valid access rights to resources have been used. The ACL mentioned here is an example of a list including only information for controlling access to a shared resource among various information included in the team data list described above.

FIG. 11 shows an outline of a conventional system for sharing information among a plurality of users using an ACL. In the system shown in FIG.
The server 5 is connected to the server 5 via the Internet 4, and sharing members 6 outside the intranet as well as those inside the intranet 1 share information with each other via the Internet 2. As is well known, the intranet 1 is a closed network such as a network provided in a company,
On the other hand, the Internet 2 is a public network that spans the world.

The firewalls 3 and 4 are computers for preventing a malicious intruder or the like from illegally accessing the intranet 1. Server 5
Is a terminal (computer) in which various resources are stored, and a database 7 in which shared information is stored, and an ACL 8 which holds a group list of members who can access specific information or functions and members belonging thereto. It has. The server 5 has a data storage function for managing shared information stored in the database 7, a user authentication function for verifying whether or not a communication partner corresponding to a client is a previously permitted person, and an ACL 8. An access control function for verifying whether or not access to the shared information is possible, and a group management function for enabling only members belonging to a specific group to access the specific shared information based on the ACL 8 are provided.

In the system shown in FIG. 11, when an access request to the database 7 is made by a shared member 6 or a user inside the intranet 1, the server 5 sends the ACL 8 each time.
, The user is authenticated. If the user is defined as a member in the ACL 8, access is permitted. If the user is not defined as a member, access is denied. If the user is permitted to access, the server 5 refers to the ACL 8 to check whether the member is included in a specific group, and determines whether the member has access to the shared information requested to be accessed. To see if they are allowed.

On the other hand, FIG. 12 shows an example of a conventional implementation for sharing information only with members belonging to a specific group. A server SV in the figure corresponds to the server 5 in FIG. CL is a terminal operated by the sharing member 6 and the person inside the intranet 1 in FIG. FIG.
In the example, the group list 9 is provided on the server SV.
The group list 9 that exists for each group includes a group ID that is an identifier assigned to the group, a public key of each member in the group, and a public key number that is an identifier assigned to these public keys (in FIG. Public key No.), and is signed by the group manager of the group.

[0007] When the client CL requests the server SV for a group list relating to a specific group with a specified group ID, the server SV performs a predetermined authority check, and then checks the group list 9 corresponding to the specified group ID. As a public key ID list to the client CL. After confirming that the signature of the group manager included in the list is valid, the client CL stores the sent group list in the public key and the public key of the member according to the member's joining or leaving the group. The group list 9a is created by adding and deleting IDs. Next, the client CL signs the group list 9a, sends a group list update request to the server SV, and returns the group list 9a. Thus, after the server SV confirms the predetermined authority, the server SV receives the group list 9b from the client CL and updates the group on the server SV.

[0008]

When resources are shared among a plurality of users, it may not be preferable to include an administrator on the server side as a shared member. For example,
It is considered necessary for a system administrator belonging to the information system department of a certain company to be unable to access the personnel information of the company that should be shared only within the personnel department. However, in the system shown in FIG. 11 and the processing procedure shown in FIG. 12, the administrator of the server 5 or the server SV is authorized to set and manage the ACL 8. Therefore, these server managers can make unauthorized access to the ACL 8, and there is a drawback that it is impossible to prevent the setting contents of the ACL 8 from being falsified intentionally. In addition to this, besides the server administrator, the server SV
AC by an unauthorized intruder (so-called cracker)
L8 may be tampered with illegally.

Further, in the conventional system as described above, it is necessary to have only a small number of server administrators set the authority, and the burden associated with such authority setting work is concentrated on these few administrators. There is also the problem of doing it. In addition, if information is shared only within the intranet, for example, in a usage form in which a company's system is entrusted to a third party outside the company and operated, the ACL8 may be changed by increasing or decreasing the number of information sharers. Whenever it becomes necessary to change the settings, it is necessary to request an operator outside the company for the setting work. Therefore, the labor and cost required for it will be a great burden,
Problems remain in terms of reliability, such as whether or not to trust external operators.

[0010] The present invention has been made in view of the above points, and an object of the present invention is to allow a server administrator storing a team data list to manage the team data list without managing the team data list. Team data that can be managed by members of the group that is the administrator itself, and that prevents server administrators, members who are members but not administrators, and crackers from modifying the team data list in advance. A list processing system is provided. Another object of the present invention is to provide a team data list processing system capable of setting a plurality of persons as managers of a team data list and reducing a work load on a specific individual. .
Still another object of the present invention is to provide a team data list in which a member who is a manager of a team data list can change the manager of the team data list without the intervention of an external person such as a server manager. It is to provide a processing system.

[0011]

In order to solve the above-mentioned problems, the invention according to claim 1 notifies a predetermined request destination of information for identifying and authenticating the instructor who issues the change instruction. A team data list prepared in accordance with the authority of members belonging to the team, the information including information on a team composed of members sharing resources with each other and the electronic signature of a master having the authority to manage the information. A list creator confirming means for confirming whether or not an authorized master has created the team data list based on the content of the acquired team data list obtained from the request destination; List change means for making a change according to the change instruction to the team data list confirmed to be created, and creating an electronic signature of the instructor,
Signature means for attaching the electronic signature to the team data list changed by the list changing means and sending the electronic signature to the request destination.

According to a second aspect of the present invention, in the first aspect of the invention, the team data list includes at least one member list including at least member information on the members and an electronic signature of the master. And a master list including at least master information indicating the authority of the master and an electronic signature of the master. The invention according to claim 3 is the invention according to claim 2, wherein the master includes a team master having authority to change the master list, and the change instruction is an instruction to change the team master, The list creator confirming means is included in the transition period member list and the transition period master list returned from the request destination corresponding to the changed member list and master list sent to the request destination. The electronic signature of the master is confirmed, and the signature unit creates an electronic signature of the changed team master specified by the change instruction, and assigns the electronic signature to the member list in the transition period and the master list in the transition period. The new member list and the new master list are sent back to the request destination.

According to a fourth aspect of the present invention, in the third aspect of the present invention, there is provided registration means for acquiring and registering identification information for identifying the team master from a predetermined place, And confirming whether or not the electronic signature of the master is the electronic signature of the team master based on the identification information of the master and the electronic signature of the master included in the member list and the master list sent from the request destination. And a team master confirming means. According to a fifth aspect of the present invention, in the invention of the fourth aspect, the team master is determined based on a change in the contents of the master list, the master list in the transition period, and the new master list acquired at the time of the change instruction. Change confirmation means for confirming that the change has been made through regular procedures, and provided that the change has been confirmed,
Identification information updating means for acquiring the identification information of the changed team master specified by the change instruction, and updating the identification information of the pre-change team master registered in the registration means with the identification information. It is characterized by:

[0014] The invention according to claim 6 includes information on a team composed of members sharing resources with each other and an electronic signature of a master having authority to manage the information.
A team data list storing means for storing a team data list prepared according to the authority of members belonging to the team, and, in response to a reference request from a predetermined request source, the team data list and the identity of the instructor who made the request A first method for judging whether or not the instructor has authority for the request based on information for performing identification and authentication, and transmitting the team data list only to a request source having an instructor having authority is provided. Authority confirmation means, for an update request from the request source, confirms the validity of the team data list based on the contents of the team data list sent from the request source,
And a second authority confirmation unit for updating the storage contents of the team data list storage unit with the team data list whose validity has been confirmed.

According to a seventh aspect of the present invention, in the sixth aspect of the invention, the team data list storage means includes at least one member including at least member information on the member and an electronic signature of the master. It has a member list storing means for storing a list, and a master list storing means for storing a master list including at least master information indicating the authority of the master and an electronic signature of the master.

According to an eighth aspect of the present invention, in the invention of the seventh aspect, the master includes a team master having a right to change the master list, and the second right confirming means includes the instruction right and the left. A master list holding unit that holds the master list before the change as an old master list in response to a change instruction of the team master notified from the user, the master list sent to the request source in response to a request from the request source, and Means for receiving, from the request source, a transition period master list and a transition period member list in which information relating to the team master is changed from the member list, and detecting a change in the team master based on these lists; Under the condition that a change is detected, the master list in the transition period, the member list in the transition period, and the old master list are displayed. Means for confirming the validity of the change of the team master, and the master list of the transition period and the member list of the transition period sent to the request source on condition that the validity is confirmed, A new master list and a new member list to which the electronic signature of the changed team master designated by the change instruction is attached are received from the request source, and the validity of these lists is confirmed, and the member list storage means and the master Means for updating the storage contents of the list storage means. According to a ninth aspect of the present invention, there is provided a team data list management device according to any one of the first to fifth aspects, which is a request source, and a team data list management apparatus according to any one of the sixth to eighth aspects, which is a request destination. And a data list storage device.

According to a tenth aspect of the present invention, there is provided a team comprising members for notifying a predetermined request destination of information for identifying and authenticating an instructor who issues a change instruction, and sharing resources with each other. Acquiring from the request destination a team data list prepared in accordance with the authority of members belonging to the team, the information including information relating to the A confirmation process for confirming whether or not the authorized master has created the team data list based on the contents of the data list;
A list change process for making a change according to the change instruction to the team data list, which is confirmed to be a creation of an authorized master by the confirmation process, and creating an electronic signature of the instructor, The electronic signature is attached to the team data list changed in the change process, and the signature is sent to the request destination, and the computer is made to execute the signature process.

The invention according to claim 11 includes information on a team composed of members sharing resources with each other and an electronic signature of a master having authority to manage the information.
A process of storing in advance a team data list prepared according to the authority of members belonging to a team, and, when a reference request is sent from a predetermined request source, the team data list and the instructor who made the request Judge whether or not the instructor has the authority of the request based on information for performing personal identification and authentication of the team, and send the team to the request source only when the instructor has authority of the request. A process of transmitting a data list, and when an update request is sent from the request source, the validity of the team data list is confirmed based on the contents of the team data list sent from the request source. Only when the performance is confirmed, the computer is made to execute an authority confirmation process of updating the stored team data list.

[0019]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, an embodiment of the present invention will be described with reference to the drawings. First, a team data list in the present invention will be described. The team data list according to the present invention is a generic name of a list that defines information about a team, and defines a “set of members” that is applied to an application requiring highly confidential management such as the ACL described above. belongs to. As described above, in the conventional system, a terminal manager, a network manager, a server manager, and the like who are not members of the team can change information about the team. On the other hand, in the team data list according to the present invention, information on a team is divided into a plurality of lists (one or more member lists and a team master list, which will be described later), and is managed. Can be performed only by members of the team.

Next, the technology on which the present invention is based will be described with reference to FIGS. FIG. 2 schematically illustrates a configuration of a system premised on the present invention, and is a system configured by connecting a client CL and a server SV via a network NW. In the figure, a member list describes members who can access resources such as various information and functions provided to the user. Further, the server SV is connected to a database 10 constructed on a hard disk or the like, and the database 10 has member lists 11A, 11A,
11B is stored.

The server SV has only a member list storage function. In addition to transferring the member list to the client CL, the server SV changes the member list and returns it to the member list 11 on the database 10.
A and the contents of the member list 11B are replaced. On the other hand, the client CL has a member list management function. One of the member list management functions is a member list change function. The client CL modifies the member list acquired from the server SV in accordance with addition or deletion of a member and returns the result to the server SV.

Here, with only the functions just described, the server administrator or the cracker can manipulate the server SV to falsify the member list on the server SV without intervening the member list management function on the client CL side. Would. In addition, if the server administrator or the like falsifies the member list with his / her signature, the client CL cannot distinguish it from the legitimate administrator. In order to avoid this kind of inconvenience, in the system of FIG. 2, signatures 12A and 12B are added to the member lists 11A and 11B, respectively.
B is added. To cope with this, the client CL has an electronic signature function as part of the member list management function, acquires a secret key from an IC (integrated circuit) card or the like in which a secret key file or a secret key is recorded, The member list is signed with the secret key and sent to the server SV, and the server SV stores the member list and the signature in pairs for each group.
By doing so, by checking the signature attached to the member list, the client CL can find that the server administrator or the like has illegally rewritten a part of the member list.

FIG. 3 shows an outline of a procedure for changing the member list on the server SV from the client CL side. In the member list 20 stored on the server SV, the members MX, MY,..., MB (actually, public key numbers corresponding to the members described below) constituting the team T1 as the information sharing group are included. In addition, a digital signature (also referred to as an electronic signature) of a team master TM (which will be described in detail later) as a manager of the team is registered in advance.

First, when changing the member list, the team master TM on the client CL side uses a group ID (identifier) for identifying a group or a team.
And sends a user public key number (user public key No. in the figure) corresponding to the user public key (that is, a bit string of a predetermined length) in the public key system to the server SV, and requests the server SV to send a member list. (Step S1). Here, the “user public key number” is information for identifying and authenticating the user himself / herself, such as the team master TM, and is a serial number assigned to each user public key in advance. More specifically, the user public key number is information corresponding to each user public key for uniquely identifying the user public key, for example, the certificate included in a certificate issued by a certificate authority. Is the serial number. Further, as information for identifying and authenticating the user himself / herself, various information such as an ID and a name for actually identifying the key creator himself / herself can be used in addition to the user public key number just described. In the following description, a case where a public key number is used as an example of such information for identifying and authenticating the user will be described.

Next, the server SV confirms the authority of the team master TM based on the group ID and the user public key number sent from the client CL, as described in detail below (step S2). First, the server SV identifies and authenticates the Team Master TM himself using a technique called “shake hand” or “challenge response”. Hereinafter, this processing will be described along the procedure shown in FIG. First, as described in step S2 of FIG. 3, when the client CL accesses the server SV, the user name and the user public key (actually, the user public key number described above) are sent to the server SV. (Step S
101). Next, the server SV generates a random number and stores it internally, and encrypts the random number with a user public key (corresponding to the user public key number) (step S102),
The encrypted data is transmitted to the client CL as “challenge data” (step S103). The client CL decrypts the challenge data sent from the server SV with a secret key corresponding to the user public key (step S
104), and returns the obtained decrypted data to the server SV as a “challenge response” (step S10).
5). The server SV compares the challenge response sent from the client CL with the random number generated in step S102 to confirm the communication partner. That is, if they match, it can be confirmed (successful authentication) that the person who knows the secret key corresponding to the user public key sent in step S101 is the communication partner. On the other hand, if the two do not match, it can be understood that the communication partner may not be a person with valid authority (authentication failed) (step S106). Thereafter, the server SV proceeds to step S10
The client CL is notified of the confirmation result (authentication success or authentication failure) obtained in step 6 (step S107).

If the authentication of the user succeeds in this way, the server SV checks whether the user public key number sent from the client CL is described in the member list 20 and checks the user (in this case, Checks whether the team master TM) has the authority to change the member list 20. Here, client C
It is assumed that the user public key number sent from L is described in the member list 20 corresponding to the team T1 specified by the group ID. Incidentally, if the user public key number is not described on the member list 20, the server SV notifies the client CL of the authentication failure. next,
The server SV accepts the request for rewriting the member list by the team master TM because the digital signature in the member list 20 is that of the team master TM, and transmits the requested member list 20 to the client CL.
(Step S3). The client CL
The digital signature in the member list 20 is checked, and since the digital signature is given by the team master TM itself, it is confirmed that the member list 20 is not falsified on the server SV side and is legitimate ( Step S
4). Next, the client CL performs a member change process of replacing the member MB in the member list 20 with the member MC to create the member list 21 (step S5).
Here, in the created member list 21, the digital signature is deleted every time the member is changed, so the client CL creates the member list 22 in which the digital signature of the team master TM is added to the member list 21 (step S).
6) and returns it to the server SV (step S
7).

From the above, according to the present invention, the management of the member list itself is performed by the administrator selected from the members in each team on the client CL side.
The server SV employs a configuration in which a person corresponding to the server administrator described above or an unauthorized person such as a cracker cannot illegally falsify the member list. The present embodiment, which will be described in detail below, is a further development based on the base technology described above, and achieves the above-described object of the present invention by incorporating the functions described below. . First, in managing a member list of a department having a large number of people, a mechanism for managing the member list by a plurality of managers is implemented in order to reduce the burden on one manager. Second, the change of the manager of the team data list by the manager of the team data list is realized. For example, there is a case where the manager who is the manager of the team data list is transferred and the succeeding manager is made the manager of the new team data list. In such a case, the current manager, who is the manager of the team data list, can delegate the manager's authority to the succeeding manager. I have to.

Hereinafter, the present embodiment will be described with respect to a system including two devices, a team data list management device and a team data list storage device. FIG.
FIG. 1 is a block diagram illustrating a configuration of an entire system according to the present embodiment including a team data list management device and a team data list storage device. In the figure, a team data list management device 30 and a team data list storage device 31 are provided with a team data list management function and a team data list storage function, respectively, which will be described in detail below. are doing. Each of the team data list management device 30 and the team data list storage device 31 can be realized by a general computer such as a workstation. Programs (team data list management program, team data list storage program) for realizing the list storage function are stored.

These programs are stored in a portable storage medium such as a floppy (registered trademark) disk, an IC (integrated circuit) card, a magneto-optical disk, a CD-ROM (compact disk-read only memory), or a computer. A part or the whole is stored in a computer-readable storage medium such as a large-capacity storage medium such as a hard disk. That is, the program may be for realizing a part of the functions described in detail below, or may be for realizing these functions in combination with a program already recorded in the computer. good. When operating the team data list management device and the team data list storage device, these programs are executed by the CPU on the computer.
It is transferred from the storage medium to the main storage in advance under the instruction of the (central processing unit). Thereafter, the CPU executes the program transferred to the main memory, thereby controlling each unit of the apparatus, and realizes various processes described in detail below.

[0030] The "computer" mentioned here is O
It includes hardware such as S (operating system) and peripheral devices. In addition, the computer-readable storage medium is not limited to the one that statically stores the program as described above, and dynamically stores the program for a short time through a communication line such as a dedicated line or a telephone line. Main memory and cache memory built into computer equipment such as servers, routers, and gateways that hold, transfer, and relay programs and data over networks such as the Internet, and volatile memory inside computers that function as servers and clients. And all that can hold the program for a certain period of time.

In the present embodiment, persons who can access the team data list are classified into three types: members, submasters, and team masters according to the contents of the authority, and the authority granted to that person is expanded in this order. I will do it. The submaster is a manager in the team designated by the team master, and cannot change the team master or the submaster, but can make additions and deletions to general members. On the other hand, a team master is a person who can change a submaster or a member, and can even change its own team master. On the other hand, general members other than the submaster and the team master are those who share information and functions, and have no authority to change the contents of the team data list. Although the submaster and the team master are given special authority, they are still members of the team, and the submaster or the team master may be called a member in that sense.

A storage device 32, such as a hard disk, capable of constructing a database is connected to the team data list storage device 31 shown in FIG. The storage device 32 stores a set of a team data list including a member list 33 and a team master list 34 for each team composed of a plurality of members. In the figure, only one set of the member list 33 and the team master list 34 is shown for the sake of explanation, but actually, there are as many such sets as the number of teams. The member list 33 is composed of a list of members sharing information and functions provided to the user, and includes identification information of the members, a public key given to the members,
The ID of the holder of the private key corresponding to this public key (hereinafter referred to as “public key ID”), the team ID for identifying the team, the signature of the list creator (that is, the team master or submaster), and the creation of the member list 33 The information includes a time stamp indicating the time of execution, information on functions (for example, applications) that can be used by members of the team, information for hierarchizing teams in a manner similar to a company organization, and the like. In addition, the member list 33 includes information such as an e-mail (e-mail) address and a member's own address as information on each member, and by using these, information resources on each member are also managed at the same time. be able to. Meanwhile, the team master list 34
Consists of a list of team masters and sub-masters.
A public key ID, a team ID, a signature of the team master, a time stamp indicating the time when the team master list 34 was created, and the like are included. In addition, the team master list 34 includes information on the team, such as the number of team members, the time when the team was created, and various functions that can be used by each member in the team. By using this, information resources for each team can be managed at the same time.

Next, in the team data list storage device 31 shown in FIG. 1, when the client CL receives a change request or a reference request for the member list 33 or the team master list 34 from the client CL side, these two lists are used. In addition to the authentication of the requester on the client CL side based on the content of the request, the requester himself / herself is checked whether the requester has a legitimate authority to make changes or references, and the member list 33 and the team master list are sent to the client CL side. 3
4 is to be transferred. In addition, the list storage function 36 manages the processing of acquiring these lists from the storage device 32 or storing them in the storage device 32 when the authority confirmation function 35 uses the member list 33 and the team master list 34. In the following description, the authority confirmation function 35 is used for the member list 33 and the team master list 34.
Is presupposed that the list storage function 36 always intervenes, but will not be described here because it becomes complicated.

Next, in the team data list management device 30, the list creator confirmation function 37 obtains the member list 33 or the team master list 34 from the team data list storage device 31, and those lists are managed by an administrator ( That is, it is verified whether it has been created by the team master or the sub master). With this verification,
It is possible to detect that an unauthorized person such as an administrator of the server SV or a cracker who has illegally entered the server SV has tampered with the member list 33 or the team master list 34. The list change function 38 changes the member list 33 and the team master list 34 acquired by the list creator confirmation function 37, such as addition, deletion, and replacement of members and managers. Further, the electronic signature function 39 uses the hash function together with the encryption using the secret key or signature key known only to the changer himself, for the member list 33 and the team master list 34 changed by the list change function 38. A digital signature of the person who changes these lists (that is, the team master or submaster) is added. On the other hand, the public key management function 40 accesses the public key database 41 connected to the team data list management device 30, and acquires a public key and a public key ID corresponding to the public key. Incidentally, in an actual form, the public key database 41 is stored in a server (for example, a certificate authority) installed on a network such as the Internet as well as a local form directly connected to the team data list management device 30. The existing form is of course also conceivable. According to such an embodiment, the public key management function 40 accesses the public key database 41 via, for example, a homepage registered on a certificate authority, and obtains the above-described public key and public key ID therefrom in a file format. Also becomes possible.

In FIG. 1, the public key database 41,
The storage device 32 is assigned to the team data list management device 3
0, the configuration is different from the team data list storage device 31. For example, the team data list management device 30 may include the public key database 41, or the team data list storage device 31 may include the storage device 32. Of course, it is also good.

Next, the operation of the system having the team data list management device 30 and the team data list storage device 31 having the above configuration will be described. First, FIG. 5 shows a processing procedure for changing a member registered in the member list among operations when members are managed by a plurality of managers. In the team data list storage device 31, since the team T2 corresponding to the team master list 45 is created by the above-described team master TM, a digital signature of the member MX as the team master is given. In the team master list 45, a member MX is registered as a team master, and members MY and MZ are registered as submasters.
In the following description, when a certain member is a team master or a submaster, those members (for example, the members MX and MY shown in FIG.
X, submaster MY, etc.

[Change of Member] In the following, it is assumed that the member MB is removed from the member due to a personnel change or the like and the member MC joins as a new member. Therefore, the submaster MY transfers the member MB belonging to the team T2 to the member MC.
Shall be replaced by First, the team data list management device 30 sends a member change request to the team data list storage device 31 together with the group ID representing the team T2 and the user public key number of the submaster MY (step S11). In the team data list storage device 31, the authority confirmation function 35 authenticates the submaster MY by the above-described shake hand, and then performs the group ID
By referring to the member list 46 relating to the team T2 specified by the above, it is confirmed that the user public key number of the member MY exists on the member list 46, and by referring to the team master list 45, the submaster M
It is confirmed that Y is a submaster of team T2 and has the authority to change members (step S12). Next, the authority confirmation function 35 transfers the team master list 45 and the member list 46 relating to the designated team T2 to the team data list management device 30 (step S1).
3).

In the team data list management device 30, the list creator confirmation function 37 has a team master list 45 transferred from the team data list storage device 31.
Then, the digital signature included in the member list 46 is collated to confirm that these lists are legitimate ones created by the person registered in the team master list 45 (that is, the team master MX) ( Step S1
4).

Here, the details of the confirmation processing performed by the list creator confirmation function 37 will be described with reference to the flowchart of FIG. First, the list creator confirmation function 37
Acquires the team master list 45 and the member list 46 from the team data list storage device 31 (step S2).
1), and then check the digital signatures included in these two lists (step S22). As a result of this check, if any one of the digital signatures has been tampered with, it is considered that an improper act has occurred, and the processing such as the current member change is stopped. On the other hand, if no tampering has been detected, the list creator confirmation function 37 determines that the signer of the member list 46 (that is, the member MX in FIG. 5) is included in the team master list 45 as the team master or submaster. Is checked, and if it is not included, it is determined that there has been an improper act, and the current processing is stopped as in step S22 (step S23).

On the other hand, if the signer of the member list 46 is included in the team master list 45,
Since the validity of the member list 46 has been confirmed, the list creator confirmation function 37 subsequently confirms whether the signer of the team master list 45 (that is, the member MX in FIG. 5) is the team master. (Step S24), and if not a team master, steps S22-
As in step S23, the processing is stopped on the assumption that an illegal act has occurred. On the other hand, if the signer of the team master list 45 is the team master, the validity of the team master list 45 has also been confirmed, and the subsequent processing is continued. For example, in the above case, the list creator confirmation function 37 sends the team master list 45 and the member list 46 to the list change function 38.

When the validity of the team master list 45 and the master list 46 is confirmed in this way, in step S15 of FIG. 5, the list change function 38 replaces the member MB described in the member list 46 with the member MC. A member list 47 is created and sent to the electronic signature function 39. The electronic signature function 39 acquires a secret key related to the submaster MY from the above-described secret key file or the like,
Based on this, a member list 48 is created by attaching the digital signature of the submaster MY to the member list 47 (step S).
16) After that, the team master list 45 and the member list 48 are returned to the team data list storage device 31 (step S17).

In the team data list storage device 31, the authority confirmation function 35 verifies whether or not the transferred team master list 45 and member list 48 have been falsified with the digital signature. Verify the contents. That is, since the signer of the team master list 45 is the team master MX, its validity can be known. On the other hand, the signer of the member list 48 is the submaster MY, and the submaster MY may be a person who is permitted to change the member by the team master MX by referring to the team master list 45 whose validity has been confirmed. Therefore, it can be trusted that the member list 48 is also valid. On the other hand, when the validity of the transferred list cannot be confirmed, the authority confirmation function 35 stops the processing without updating the team master list and the member list (step S18). As described above, the members in the member list are changed.

[Change of Submaster] Next, a processing procedure when the team master changes the submaster will be described with reference to FIG. Hereinafter, the team master MX belonging to the team T2 assigns the member MY as a sub member to the member MW.
Is assumed to be replaced with When the team master MX makes a request to the team data list management device 30 to change the submaster from the member MY to the member MW, the list creator confirmation function 37 in the team data list management device 30 performs the same operation as in step S11 in FIG. A submaster change request is transmitted to the team data list storage device 31 together with the ID and the user public key number of the team master MX (step S31). In the team data list storage device 31, the authority confirmation function 35 is executed in step S of FIG.
After the team master MX is authenticated by the shake hand according to the same procedure as described in step 12, it is confirmed that the user public key number of the member MX is described in the member list 46, and the member MX T
It is confirmed that the second master is authorized to change the submaster (step S32). next,
The authority confirmation function 35 transfers the team master list 45 and the member list 46 to the team data list management device 30 in the same manner as in step S13 of FIG. 5 (step S3).
3).

In the team data list management device 30, the list creator confirmation function 37 checks the digital signature included in the transferred team master list 45. As a result, the list creator confirmation function 37 confirms that the team master list 45 is valid by the member MX as the team master, and passes the team master list 45 and the member list 46 to the list change function 38. (Step S34). List change function 38
Creates a team master list 51 in which the submaster MY described in the team master list 45 is replaced with the submaster MW, and sends this to the electronic signature function 39 (step S35).

The electronic signature function 39 obtains a secret key related to the team master MX from the above-mentioned secret key file or the like,
After creating a team master list 52 in which the digital signature of the team master MX is attached to the member list 51 (step S36), the team master list 52 and the member list 46 are returned to the team data list storage device 31 (step S37). . In the team data list storage device 31, the authority confirmation function 35 stores the transferred contents of the team master list 52 and the member list 46 in FIG.
Verification is performed according to the same procedure as in step S18. In this case, since the signers of the team master list 52 and the member list 46 are both the team masters MX, their legitimacy is known. On the other hand, if the validity of the transferred list cannot be confirmed, the authority confirmation function 35 stops the processing without updating the team master list and the member list (step S38). As described above, the submaster in the team master list has been changed.

In the example shown in FIG. 7, the original digital signature of the member list 46 is that of the team master MX, but there is no problem even if this is the signature of the submaster MY. That is, the team master MX having the authority to change the submaster can always give its own signature to the member list 46. Therefore, in this case, the digital signature of the submaster MY is deleted from the member list 46 on the team data list management device 30 side, and the signature of the team master MX is attached and returned to the team data list storage device 31 instead. . By doing so, the member list with the digital signature of the submaster MY who is no longer a member does not remain on the team data list storage device 31 side.

[Change of Team Master] Next, a processing procedure when the team master changes the team master will be described with reference to FIG. In the following, Team Master M
It is assumed that X delegates authority to the team master MK and changes the team master. The team master list 45 stored in the team data list storage device 31 is the same as that shown in FIG. 5 or FIG. 7, and the member list 48 is the same as that after the member change shown in FIG.

First, when the team master MX requests the team data list management device 30 to change the team master to a member MK, the list creator confirmation function 37
A request to refer to the team master list 45 and the member list 48 together with the group ID and the user public key number of the team master MX is sent to the team data list storage device 31 in the same manner as step S11 in FIG. 5 (step S4).
1). In the team data list storage device 31, the authority confirmation function 35 authenticates the member MX by the shake hand according to the same procedure as described in step S12 of FIG. 5, and then the user public key number of the member MX is changed to the member list. 48, and that the member MX is the team master of the team T2 and has the authority to refer to the requested list (step S42).

Next, the authority confirmation function 35 transfers the team master list 45 and the member list 48 relating to the designated team T2 to the team data list management device 30 in the same manner as in step S13 of FIG. 5 (step S43).
At this time, the authority confirmation function 35 saves the team master list 45 for use in authority confirmation performed later. Next, in the team data list management device 30,
The list creator confirmation function 37 checks the digital signatures of the transferred team master list 45 and member list 48, respectively, and each is a legitimate one created by the team master MX and submaster MY included in the team master list 45. Is confirmed (step S44). As a result, the list creator confirmation function passes the two transferred lists to the list change function 38.

Next, the list change function 38 replaces the team master member MX described in the team master list 45 and the member list 48 with the member MK, and creates a team master list 55 and a member list 56, respectively. (Step S4)
5). The electronic signature function 39 obtains a secret key related to the team master MX from the above-described secret key file or the like, and adds a team master list 57 and a member list 58 each having the digital signature of the team master MX attached to the team master list 55 and the member list 56, respectively. It is created and returned to the team data list storage device 31 (step S46).

In the team data list storage 31, the authority confirmation function 35 performs three lists of the transferred two lists and the team master list 45 (that is, the old team master list) stored in the previous step S 43. , The authority is confirmed in accordance with the flowchart shown in FIG. 9 (step S47). FIG. 10 shows a state of a team master list and a member list that are compared and collated in each step of FIG. 9 when such authority confirmation is performed.

First, the authority confirmation function 35 is used as the new and old team master lists, respectively.
5 and a member list 58 as a new member list (step S61). Next, the authority check function 35 checks the digital signatures of the team master list 57 and the member list 58 (step S6).
2). If any of them has been tampered with, the two lists are sent from the team data list management device 30 (client CL) to the team data list storage device 31.
Since the fraud has occurred during the transfer to the (server SV), the authority confirmation function 35 cancels the team master change process.

On the other hand, if neither of the transferred two lists has been tampered with, the authority confirmation function 35 checks the digital signature of the new team master list 57 and finds that it is the same team as the signer of the old team master list 45. It is confirmed that it is due to the master MX (step S63). This is to confirm that authority transfer has been performed by the person who was originally the team master.
If the result of the determination in step 3 is "NO", it is considered that there is an improper act due to a violation of authority or the like, and the team master changing process is stopped.

However, in this case, since the digital signature of the member MX is attached to the team master list 57, the authority confirmation function 35 continues to discriminate between the change of the team master itself and other normal changes. Next, it is confirmed whether or not the signer of the new team master list 57 has master authority (step S64). For example, in the member change described in FIG. 5 described above, the digital signature of the team master list 45 is obtained by the member MX having master authority, and the same applies to the team master 52 in the submaster change in FIG. 7 ( That is, when the determination result of step S64 is “YES”).

On the other hand, in the case where the team master itself is changed, the processing time of step S47 in FIG.
Corresponds to the transition period in which the authority is delegated to the member MK,
The team master list 57 is in a transitional state in which the member MK as the new manager is the master and the member MX as the old manager signs, and the signer of the team master list 57 does not have the master authority. Looks like. If such a state is detected and the change of the team master itself is recognized (the determination result in step S64 is “NO”), the authority confirmation function 35 checks the digital signature of the new member list 58, and the digital signature is It is checked whether it is included in the list 57 or, otherwise, whether it is the signer of either the new or old team master list 57, 45 (step S65). If neither condition is satisfied, it is considered that an illegal act such as tampering has occurred, and the authority confirmation function 35 stops the team master change process. However, in this case, since the signer of the member list 58 is the same as the signer of the new and old team master lists 57 and 45, the authority confirmation function 35 may determine that the member list has been created through a regular procedure. it can. Through the processing in steps S62 to S65 described above, it can be determined that the team master MX itself has been changed by a normal operation by the team master MX having valid authority.

Thereafter, the authority confirmation function 35 sends the new and old team master lists 57 and 45 and the member list 58 to the team data list management device 30 (step S48).
Subsequent processing is performed under the instruction of the new team master MK, and is for rewriting the digital signature of the team master list 57 and the member list 58 with the digital signature of the team master MK. In the team data list management device 30, the list creator confirmation function 5
7 checks the digital signature included in each transferred list (step S49). That is, the list creator confirmation function 37 confirms that the digital signatures of the old team master list 45 and the new member list 58 have not been falsified, and then the digital signatures of the new and old team master lists 57 and 45 match each other. Check if
Further, based on the contents of the old team master list 45, it is confirmed whether or not the member MX who is the signer of the list has the authority of the team master. In this case, since all of the three conditions just described are satisfied, the list creator confirmation function 37 outputs the team master list 57 and the member list 5
8 to the list change function 38.

Next, the list change function 38 creates a team master list 59 and a member list 60 based on the team master list 57 and the member list 58, and passes them to the electronic signature function 39. The electronic signature function 39 obtains a secret key related to the member MK from the above-described secret key file or the like, and adds the member MK to the team master list 59 and the member list 60.
A digital signature of K is attached to create a team master list 61 and a member list 62, and these lists are returned to the team data list storage device 31 (step S5).
0). In the team data list storage device 31, the authority confirmation function 35 transmits the transferred team master list 61.
Then, authority is confirmed for the member list 62 according to the processing procedure shown in FIG. 9 (step S51). In this case, since both of the signers of these two lists are team masters MK, it can be determined that both of these two lists are valid. In this case, since this is a normal change, the determination result in step S64 in FIG. 9 is “YES”. However, if the validity of the transferred list cannot be confirmed, the authority confirmation function 35 stops the processing without updating the team master list and the member list. Thus, the team master itself has been changed.

During the transition period from step S47 to step S51 shown in FIG. 8, the team data list management device 30 sends the team data list storage device 3
When a member list reference request, a member list change request, and a master change request are made to 1, the list creator is confirmed in the team data list management device 30 and the team data list storage device 31 as follows.

First, when there is a member list reference request from the team data list management device 30, the team data list storage device 31 transfers the old team master list 45 and the new member list 58 to the team data list management device 30. In the team data list management device 30, the list creator confirmation function 37 confirms whether or not the digital signatures of the two transferred lists have been falsified, and based on the contents of the old team master list 45, It is checked whether the signer (member MX in FIG. 8) has the authority of the team master.

On the other hand, when there is a member list change request or a master change request from the team data list management device 30,
The team data list storage device 31 transfers the new and old team master lists 57 and 45 and the new member list 58 to the team data list management device 30. In the team data list management device 30, the list creator confirmation function 37 confirms whether the digital signatures of the two transferred lists have been falsified, as in the case of the member list reference request. Next, the list creator confirmation function 37 compares the digital signatures of the new and old team master lists 57 and 45 with each other to confirm whether or not they match. Next, the list creator confirmation function 37 confirms whether the signer of the old team master list 45 has the authority of the team master, as in the case of the member list reference request.

[Automation of Team Master Confirmation] In the above-described embodiment, each time the team data list is used, the user needs to confirm on the client CL side whether or not the team master is genuinely correct. For example, on the display of the computer constituting the team data list management device 30, "This list is normally managed with the following members as managers. Name: Member M
X, organization: Mitsubishi Materials Corporation. If you want to continue the work, click the OK button with the mouse. "A message such as" The user is required to check the message visually, which is annoying to the user. In order to improve this point, the following functions are added as new functions in cooperation with the list creator confirmation function 37, or as one function of the list creator confirmation function 37. It is solved by incorporating.

That is, the public key of the team master is registered in advance in, for example, the public key database 41 (see FIG. 1) on the client CL side for each team, and the public key management function 4 is registered.
0 obtains the public key of the team master from the public key database 41 and notifies the list creator confirmation function 37 of this. Alternatively, a serial number or the like for identifying a public key is registered in the public key database 41 as information on the public key, and after the public key management function 40 acquires this serial number from the public key database 41, A public key registered outside the team data list management device 30 (for example, on the Internet) may be separately acquired and passed to the list creator confirmation function 37.

On the other hand, the list creator confirmation function 37 does not output the above-mentioned message on the display of the computer, but stores the team data list based on the public key of the team master notified from the public key management function 40. By confirming the digital signature included in the team master list transferred from the device 31, it is determined whether the signature belongs to the team master. This allows the user to verify the legitimacy of the team master without visually confirming it based on the display on the display.

[Automation of Team Master Confirmation When Changing Team Master] By the way, as shown in FIG.
If it is changed to K, it is no longer a member M who is the old administrator
The public key of X cannot be used. for that reason,
It is necessary to automatically change the public key of the team master registered on the client CL side without user intervention. In order to realize such a change process, the following process may be performed after the final team master list 61 (see FIG. 8) is created (that is, after step S51).

First, in the team data list storage device 31, the authority confirmation function 35 stores the old team master list, the team master list in the transition period, and the final team master list (that is, the team master lists 45, 57, 61) in the respective teams. The data is transferred to the data list management device 30. In the team data list management device 30, the list creator confirmation function 37 knows through the public key management function 40 that the member MX is registered in the public key database 41 as a team master. Next, list creator confirmation function 3
7 can confirm from the three lists transferred from the team data list storage device 31 that the member MX as the old manager has delegated authority to the member MK as the new manager in accordance with a regular procedure.

This is because the team master lists 45 and 5
The team masters registered in 7, 61 respectively transition from member MX → member MK → member MK, while the digital signatures attached to these lists are member MX → member MX → member MK, respectively. Has transitioned. Therefore, the list creator confirmation function 37
Is the public key database 4 via the public key management function 40.
In step 1, the public key of the person registered as the team master is changed from that of the member MX to that of the member MK. Since the change of the team master is not so complicated, the user may be asked to confirm the change when performing the change process. Further, it goes without saying that various information other than the public key can be used as information for confirming the team master.

In the above-described embodiment, only one member list is provided. However, even when a plurality of member lists are used, the change of the team master itself and the resource management by the plurality of team masters can be performed. Can be realized. For example, the member list may be subdivided into two or more member lists in accordance with the authority of each member. This makes it possible to make the information shared by members belonging to each member list different according to the member list.

As described above, in the recording medium on which the team data list management program is recorded, the team data list management program stores (1) information for identifying and authenticating the instructor who issues the change instruction at a predetermined request destination. And information on a team composed of members sharing resources with each other, and a digital signature of a master who has authority to manage the information, and team data prepared according to the authority of members belonging to the team. A process of acquiring a list from the request destination; (2) a confirmation process of confirming whether or not an authorized master has created the team data list based on the acquired contents of the team data list; 3) adding a change according to the change instruction to the team data list, which is confirmed to be a creation of an authorized master by the confirmation processing; And (4) creating a digital signature of the instructor, attaching the digital signature to the team data list changed in the list change processing, and sending the list to the request destination. Let it. In addition, the above-mentioned team data list management program may include one or more member lists including at least the member information regarding the members and the electronic signature of the master, master information indicating the authority of the master, and the electronic signature of the master. At least the included master list is used as the team data list. Further, in the above-described team data list management program, the master includes a team master having a right to change the master list, the change instruction is a change instruction of the team master, and the confirmation processing includes the change of the master list. Sending the registered member list and master list to the request destination; and transmitting the electronic signature of the master included in the transition period member list and the transition period master list returned from the request destination in response to the process. Confirming, and the signature process includes a process of creating an electronic signature of the changed team master specified by the change instruction, and a process of adding the electronic signature to the transition period member list and the transition period master list. Sending back the new member list and the new master list with the signature to the request destination. In addition, the above-described team data list management program obtains identification information for performing identity identification of the team master from a predetermined location and pre-registers the identification information. A process of confirming whether or not the electronic signature of the master is the electronic signature of the team master based on the electronic signature of the master included in the member list and the master list sent to the computer. It may be the one that causes it. Further, the above-mentioned team data list management program changes the team master through a regular procedure based on the transition of the contents of the master list, the master list during the transition period, and the new master list acquired at the time of the change instruction. And confirming the change, and when the change is confirmed, acquiring the identification information of the changed team master specified in the change instruction, and using the identification information, the pre-registered team master before the change. May be further executed by a computer.

On the other hand, in the recording medium on which the team data list storage program is recorded, the team data list storage program includes (1) information relating to a team composed of members sharing resources with each other and a master having management authority for the information. (2) when a reference request is sent from a predetermined request source, a storage process for storing a team data list prepared in advance according to the authority of members belonging to the team. Based on the team data list and information for identifying and authenticating the instructor who made the request, it is determined whether or not the instructor has the authority of the request, and the instructor has the authority of the request. (3) sending the team data list to the request source only when the request source has an update request;
Authority to confirm the validity of the team data list based on the contents of the team data list sent from the request source, and to update the stored team data list only when the validity is confirmed And causing the computer to execute the confirmation processing. In the above-described team data list storage program, the storage process includes a process of storing in advance one or more member lists including at least member information on the members and an electronic signature of the master, The computer may execute a process of storing in advance master information indicating authority and a master list including at least the electronic signature of the master.

Further, in the above-mentioned team data list storage program, the master includes a team master having the authority to change the master list.
A process of storing the master list before the change as the old master list when the request source notifies the change instruction of the team master by the instructor; and a process of storing the master list and the member by a request from the request source. A process of sending a list to the request source, receiving from the request source a transition period master list and a transition period member list in which information relating to the team master has been changed, and detecting the change of the team master. And when the change of the team master is detected, a process of confirming the validity of the change of the team master based on the master list of the transition period, the member list of the transition period, and the old master list; When the validity of the change is confirmed, the master list in the transition period and the member list in the transition period are sent to the request source. A new master list and a new member list to which the electronic signature of the changed team master specified in the change instruction is attached are received from the request source and the validity is confirmed for these lists, and the validity is confirmed. And updating the stored member list and the stored master list only in the case where the information is stored.

[0071]

As described above, according to the present invention, a team data list such as a master list and a member list stored in a server or the like is acquired in accordance with a change instruction from a master having valid authority. After confirming that these lists were legitimately created by the authorized master,
The list is modified and returned to the requester. From this, it is possible to detect that an unauthorized person such as a general member other than the master, a server administrator, a cracker or the like has manipulated the team data list illegally. Further, in the present invention, since the team master itself can change the team master, the authority transfer of the team master can be realized without the intervention of an administrator such as a server storing the team data list. In addition, since a system in which the team data list is managed by a plurality of managers can be realized, it is possible to reduce the burden on a small number of managers. In the present invention,
Since the signature of the master is included in the team data list, it is possible to detect unauthorized acts such as tampering performed on the team data list. Further, in the present invention, when a reference request or an update request of the team data list is made, the authority check is performed to determine whether or not the instructor who made these requests is an authorized person. Unauthorized acts by unauthorized persons can be prevented. Further, in the present invention, information for identifying and authenticating the team master itself such as a public key is registered in advance, and is compared with the electronic signature of the master in the team data list, and when the team master is changed, Detects such a change and appropriately updates the public key and the like of the registered team master. For this reason, it is not necessary for the user to visually check the team master every time the team data list is operated, and the team master can be automatically approved.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a configuration of a system having a team data list management device and a team data list storage device according to an embodiment of the present invention.

FIG. 2 is a first diagram for explaining the technology underlying the present invention, and is a block diagram showing a configuration in which a member list management function and a storage function are divided between a client and a server.

FIG. 3 is a second diagram for explaining the technology on which the present invention is based, and is an explanatory diagram showing a processing procedure when a member included in a member list on a server is changed from a client side; It is.

FIG. 4 is an explanatory diagram showing a procedure of a technique called a shake hand or a challenge response used by a server when confirming the authority of a user at a client side.

FIG. 5 is an explanatory diagram showing a processing procedure regarding a member change in a case where members are managed by a plurality of administrators in the embodiment.

FIG. 6 is a flowchart showing a list creator confirmation process performed on the client side in the embodiment.

FIG. 7 is an explanatory diagram showing a processing procedure regarding submaster change in a case where members are managed by a plurality of administrators in the embodiment.

FIG. 8 is an explanatory diagram showing a processing procedure for changing a team master in the case where members are managed by a plurality of managers in the embodiment.

FIG. 9 is a flowchart showing a procedure of authority confirmation processing performed on the server side when the team master shown in FIG. 8 is changed in the embodiment.

FIG. 10 is an explanatory diagram showing a state of a team master list and a member list which are compared and collated in each step of FIG. 9 when the authority confirmation shown in FIG. 9 is performed in the embodiment.

FIG. 11 is a block diagram showing a configuration of a conventional system for sharing information using an access control list.

FIG. 12 is an explanatory diagram showing a processing procedure performed between a client and a server in order to share information only with members belonging to a specific group.

[Explanation of symbols]

30 team data list management device, 31 team data list storage device, 32 storage device, 33 member list, 34 team master list, 35 authority checking function,
36: list storage function, 37: list creator confirmation function,
38: List change function, 39: Digital signature function, 40: Public key management function, 41: Public key database, CL: Client, SV: Server

 ──────────────────────────────────────────────────続 き Continued on the front page F term (reference) 5B017 AA01 BA06 BB06 CA16 5B082 EA11 GA11 GA14 5J104 AA07 AA09 KA01 KA05 KA06 LA03 PA07

Claims (11)

[Claims] 1. A method according to claim 1, wherein information for identifying and authenticating an instructor who issues a change instruction is notified to a predetermined request destination, and information relating to a team composed of members sharing resources with each other and management of the information An electronic signature of a master having authority is included, a team data list prepared according to the authority of members belonging to the team is acquired from the request destination, and the authority is determined based on the acquired contents of the team data list. List creator confirming means for confirming whether or not the master having created the team data list; and responding to the change instruction with respect to the team data list confirmed to be a master having the authority. A list changing means for making a change; and an electronic signature of the instructor is created, and the electronic signature is attached to the team data list changed by the list changing means and sent to the request destination. Team data list management apparatus characterized by comprising a signature unit. 2. The team data list includes at least one member list including at least member information on the member and an electronic signature of the master, master information indicating authority of the master, and an electronic signature of the master. 2. The team data list management device according to claim 1, further comprising a master list including at least one. 3. The master includes a team master having a right to change the master list, wherein the change instruction is a change instruction of the team master, and the list creator confirming means transmits the request to the request destination. Confirming the electronic signature of the master included in the transition period member list and the transition period master list returned from the request destination in response to the changed member list and master list, wherein the signature unit includes: A digital signature of the changed team master specified in the change instruction is created, and a new member list and a new master list in which the electronic signature is added to the member list in the transition period and the master list in the transition period are sent to the request destination. 3. The team data list management device according to claim 2, wherein the team data list is sent back. 4. A registration means for acquiring and registering identification information for identifying the team master from a predetermined location, identification information of the team master, and the member list sent from the request destination. The system according to claim 1, further comprising: a team master confirmation unit configured to confirm whether or not the electronic signature of the master is the electronic signature of the team master based on the electronic signature of the master included in the master list. 3. The team data list management device according to 3. 5. A change for confirming that the team master has been changed through a regular procedure based on a change in the contents of the master list, the master list in the transition period, and the new master list acquired at the time of the change instruction. Confirmation means, and on condition that the change is confirmed, obtains the identification information of the changed team master specified in the change instruction,
5. The team data list management device according to claim 4, further comprising: identification information updating means for updating the identification information of the team master before the change registered in the registration means with the identification information. 6. Team data that includes information about a team composed of members sharing resources with each other and an electronic signature of a master who has authority to manage the information, and is prepared according to the authority of members belonging to the team. A team data list storage means for storing a list; and a reference request from a predetermined request source, based on the team data list and information for performing identification and authentication of the person who made the request. Judge whether or not he / she has the authority of the request, and sends the team data list only to a request source having an authorized instructor.
Means for confirming the validity of the team data list based on the contents of the team data list sent from the request source in response to the update request from the request source, A team data list storage device, comprising: a second authority confirmation unit for updating the storage content of the team data list storage unit with a data list. 7. The team data list storage means, member list storage means for storing at least one member list including at least member information on the member and the electronic signature of the master, and indicating authority of the master. 7. The team data list storage device according to claim 6, further comprising: master list storage means for storing a master list including at least master information and an electronic signature of the master. 8. The master includes a team master having authority to change the master list, and the second authority confirming means responds to the change instruction of the team master notified by the instructor. A master list holding means for holding a previous master list as an old master list; and a changed transfer of information on the team master among the master list and the member list sent to the request source in response to a request from the request source. Means for receiving a master list of the transition period and a member list of the transition period from the request source, and detecting a change of the team master based on these lists; and, provided that the change is detected, the master list of the transition period Means for confirming the validity of the change of the team master based on the member list in the transition period and the old master list And an electronic signature of the changed team master specified in the change instruction for the transition period master list and the transition period member list sent to the request source on condition that the validity has been confirmed. Receiving a new master list and a new member list attached from the request source, confirming the validity of these lists, and updating the storage contents of the member list storage means and the master list storage means. The team data list storage device according to claim 7, wherein: 9. The team data list management device according to any one of claims 1 to 5, which is a request source, and the team data list storage device according to any one of claims 6 to 8, which is a request destination. A team data list processing system comprising: 10. A predetermined request destination is notified of information for identifying and authenticating an instructor who issues a change instruction, and information relating to a team composed of members sharing resources with each other and management of the information A process of acquiring from the request destination a team data list including the electronic signature of the master having the authority and prepared according to the authority of the members belonging to the team, based on the content of the acquired team data list, A confirmation process for confirming whether or not an authorized master has created the team data list; and the change instruction for the team data list confirmed to be an authoritative master by the confirmation process. List change processing for making a corresponding change, creating an electronic signature of the instructor, attaching the electronic signature to the team data list changed in the list change processing A recording medium recording a team data list management program for causing a computer to execute a signature process to be sent to the request destination. 11. A team data list including information on a team composed of members sharing resources with each other and an electronic signature of a master having the authority to manage the information, and prepared according to the authority of the members belonging to the team. Is stored in advance, and when a reference request is sent from a predetermined request source, the team data list and the identification and identification of the instructor who made the request
Determining whether or not the instructor has the authority for the request based on information for performing authentication, and sending the team data list to the request source only when the instructor has the authority for the request When the update request is sent from the request source, the validity of the team data list is confirmed based on the contents of the team data list sent from the request source, and the validity is confirmed. And a recording medium for recording a team data list storage program for causing a computer to execute an authority confirmation process for updating the stored team data list only in a case where the program is executed.