JPH0895844A - Method for managing security of object-oriented data base - Google Patents

Abstract

PURPOSE: To lighten the burden on an application programmer and to enable more detailed control to be performed by inspecting whether or not access to an object is right when the object is accessed. CONSTITUTION: The object 21A is provided with key data 215 indicating another object that the object 21A has the right to access. At a request to access the object 21B which is made by the object 21A, the key data 215 is passed to the request destination object 21B together with an argument, and the request destination object 21B inspects access property inspection as to whether or not access to itself is allowed on the basis of the key data 215 passed from the object 21A and the its object identifier 211 by using a security inspection part 213 prepared as part of a procedure 212.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an object-oriented database (OOD) which is accessed by a plurality of users.
The present invention relates to an object-oriented database system including B), and more particularly to a security management method for an object-oriented database that enables finer control of access rights to objects.

[0002]

2. Description of the Related Art Generally, in a database (object-oriented database) on an object-oriented database system, objects expressing data are related to each other and often share common objects. Therefore, unlike the case of the relational database, it is not possible to restrict access for each attribute of data or to restrict access for a group of a plurality of data (for example, a group of tables).

Therefore, conventionally, in order to realize the security for each user in the object-oriented database, the function is realized by an application program.

That is, conventionally, as shown in the processing procedure in FIG. 2B, when an access request is made from an object (step 201b), the application program checks whether or not the access is valid. If the result is valid (step 202b),
The actual access request for the target object is issued from the application program (step 20).
3b), processing of the accessed object (accessed processing) is performed (step 204b). If the result of the check in step 202b is invalid, the access request is rejected (step 2).
05b).

[0005] Here, the validity of the access in step 202b is checked by checking the static access permission / prohibition flag of the accessed object itself,
It is decided from the password information from the user, and consists of several steps. Also,
A series of processes 2 from the access validity check (step 202b) to the actual access request (step 203b)
06b was incorporated in the application program. For this reason, it is necessary to prepare a very rough inspection or prepare a logic of various objects for each application program depending on the object to be accessed.

[0006]

As described above, conventionally, security management in an object-oriented database is performed on a user-by-user basis, and it is general to leave most of it to application programs. Therefore, the load on the application programmer is large,
There is also a problem that it is not possible to finely control access rights as database sharing progresses.

The present invention has been made in consideration of the above circumstances, and an object thereof is to provide a security management method for an object-oriented database which can restrict access between arbitrary objects and protect the objects from unauthorized access. To do.

Another object of the present invention is to provide information describing access rights between objects to the objects to which the access rights are given, and to provide each object or object-oriented database system with a procedure for checking the access rights. Therefore, it is to provide a security management method for an object-oriented database that can hide and protect the access right description information and the access right inspection procedure from the user.

Still another object of the present invention is that when the second object is accessed by the first object, the second object is processed by the second object as a part of the processing by the second object. Access to the third object even if the second object is not allowed to access the third object, the access can be controlled by using the access right from the first object to the third object. Therefore, it is possible to collectively restrict access to a plurality of data (object groups), and to provide a security management method for an object-oriented database that enables security management for each user.

Still another object of the present invention is that when the second object is accessed by the first object, as a part of the processing by the second object, the second object is processed by the third object. Access can be controlled by using the access right from the second object to the third object, so that only the access right can be set for the first object. , It is possible to access all the third objects that are the constituents of the second object that are allowed access by the access right of the first object, and thus access to each of several objects having a complicated relationship. Providing a security management method for object-oriented databases that does not need to set rights one by one In the Rukoto.

Still another object of the present invention is that, as a part of the processing in the second object when the second object is accessed from the first object, the second object is processed by the third object. Even when the access from the second object to the third object is not permitted when accessing, the access can be controlled by using the access right from the first object to the third object, An object of the present invention is to provide a security management method for an object-oriented database that can be controlled even by using the access right from the second object to the third object.

[0012]

A security management method (of an object-oriented database) according to the first aspect of the present invention relates to each object on an object-oriented database from that object to another object or a group of objects. If management information associated with access rights is prepared and an access request from one object on the object-oriented database to another object occurs, the validity of the access is checked according to the management information. It is characterized by doing so.

In such a configuration, as the management information, an access right list table indicating whether or not each object on the object-oriented database has an access right from that object to another object or object group is prepared. Here, assuming that an access request from the first object to the second object occurs, an object-oriented database management system (hereinafter, simply referred to as a management system) or a request before the requested processing is started. The access right list table is referred to by a part of the procedure of the previous object, the validity of the access from the first object to the second object is checked, and only when it is determined to be valid, the first Accessed processing is permitted in the second object.

This makes it possible to restrict access between arbitrary objects and protect the objects from unauthorized access. In addition, instead of the access right list table, an attribute (part of) of the object that has access right description information that describes access rights between objects
It is also possible to carry out access validity check with a special object having the information.

In the security management method according to the second aspect of the present invention, each object on the object-oriented database is provided with another object or a group of objects to which the object has an access right (that is, accessible from the object). When you have key data that is the data that you represent, and you want to access another object from one object on the object-oriented database, output the key data that you have with the argument for the requested process The validity of access to the access request destination object indicated by the value based on the key data from the access request source object and the value that identifies the access request destination object, according to some of the procedures of the object Is characterized by the fact that That.

In such a configuration, for example, when the second object is accessed from the first object, when the access request is made, the first object together with other arguments (the original arguments used in the requested process) The key data held by the object is output. This key data is
A value that is passed to the second object of the request destination and is specified by the security checking means prepared as a part of the procedure of the second object, for example, the object identifier (object identifier ( OI
Input with D). Then, the security checking means checks by the input key data whether or not the second object of the access request destination indicated by the input object identifier is shown as an object accessible from the first object, and the access is confirmed. Justification is judged.

In this way, the data (key data) describing the access right is provided to the object, and the inspection means for the presence or absence of the access right is provided as a part of the processing procedure of the object. It is possible to hide and protect the access right inspection procedure from the application program (user) and other objects. Moreover, compared with the method according to the first aspect,
The amount of data describing access rights between objects can be small.

It is also possible to perform the access validity check at the access request destination by the management system. In the security management method according to the third aspect of the present invention, the first object has the access right to the second object, and the first object has the third object as a part of the processing requested to the second object. When a specific process for accessing the object is included, when the second object accesses the third object according to the specific process, by specifying the key data passed from the first object, The validity of access from the second object to the third object is checked based on the key data of the first object that is the access request source for the second object.

In this configuration, when the second object is accessed from the first object, the second object is accessed.
When the second object accesses the third object as part of the processing in the object of
The key data (key data held by the first object) passed from the first object that accessed the second object is passed to the third object. Then, in the third object, the security inspection means prepared as a part of the processing procedure causes the second object to be extracted based on the key data of the first object and the object identifier of the third object. The validity check of the access to the third object, that is, the second object to the third object as a part of the processing in the second object when the second object is accessed from the first object Access to the object is validated.

As a result, even if the access to the third object, which is not originally permitted to the second object, is made by using the access right from the first object to the third object, The second, as part of the access from the object to the second object
Access to the third object from the object can be performed. Therefore, it is possible to collectively restrict access to a plurality of data (object groups) and perform security management for each user.

In the security management method according to the fourth aspect of the present invention, the first object has an access right to the second object and a part of the processing requested by the first object to the second object. When the third object is accessed from the second object according to the specific processing, when the third object is included as a specific processing and the second object has an access right to the third object. Specifies the legitimacy of access from the second object to the third object by specifying the key data of the second object itself, and the key data of the direct access request source of the second object. It is characterized in that it was originally tested.

In this configuration, when the second object is accessed by the first object, the second object is accessed.
When the second object accesses the third object as part of the processing in the object of
The key data held by the second object is passed to the third object. Then, in the third object, the security inspection means prepared as a part of the processing procedure is used to determine the second object from the second object based on the key data of the access request source and the object identifier of the third object. Validity check of access to the third object, that is, from the first object to the second
The validity check of the access from the second object to the third object is performed as a part of the processing in the second object when the object is accessed.

Thus, if only the access right is set only for a certain object, it becomes possible to access all the objects related to the object permitted to be accessed by the access right. Therefore, it is not necessary to set access rights for each of a number of objects having a complicated relationship.

In the security management method according to the fifth aspect of the present invention, the first object has an access right to the second object, and a part of the processing requested by the first object to the second object. When the third object is accessed by the second object in accordance with the specific processing for accessing the third object, the key data passed from the first object and the second object By linking with the key data of the object of to generate new key data, and by specifying this new key data, as a part of the processing when the second object is accessed from the first object The legitimacy of the access from the second object to the third object, which is performed based on the new key data linked above Characterized by being adapted to inspect.

In this structure, when the second object is accessed from the first object, the second object is accessed.
When the second object accesses the third object as part of the processing in the object of
The data obtained by linking the key data (key data held by the first object) passed from the first object that accessed the second object and the key data held by the second object is new. It is passed to the third object as key data. And the third
In this object, the key data passed from the second object that is the access request source (both the key data held by the first and second objects are processed by the security checking means prepared as part of the processing procedure). Based on the (connected data) and the object identifier of the third object, the legitimacy of access from the second object to the third object is checked. This makes it possible to simultaneously realize two access controls applied by the security management methods according to the third and fourth aspects.

[0026]

Embodiments of the present invention will be described below with reference to the drawings. [First Embodiment] FIG. 1 is a block diagram showing the first embodiment of the present invention.

In FIG. 1, 1A is an access request source object, and 1B is an access request destination object of the object 1A. Reference numeral 2 is an access right list table for associating access rights between arbitrary objects. In this table 2, the access request source 2
Any object that can be a and the access request destination 2b
Access permission / non-permission information 2c indicating whether or not access is permitted is held for all combinations of arbitrary objects that can be:

An object-oriented database management system (OODBMS) 3 manages an object-oriented database (not shown) that stores an object group including the objects 1A and 1B. When the access request source object (1A) makes an access request to the access request destination object (1B), the management system 3 refers to the access right list table 2 to check the validity of the access. It has an inspection unit (hereinafter, referred to as a security inspection unit) 3a.

Next, the operation of the configuration of FIG.
A case where an access request from A to the object 1B is generated will be described with reference to the flowchart of FIG.

First, when an access request from the object 1A to the object 1B is generated (step 201)
a), the security inspection unit 3a in the management system (OODBMS) 3 finds from the access right list table 2 that the access request source 2a is the object 1A and the access request destination 2
When b is the object 1B, the access permission / non-permission information 2c is searched, and the validity of the requested access is checked based on the information 2c (step 202a).

When the management system 3 determines that the access from the object 1A to the object 1B is permitted as a result of the access validity check in step 202a, it passes the message from the object 1A to the object 1B. As a result, the process of the accessed object 1B (accessed process) is the object 1A.
According to the message from (step 203)
a). On the other hand, when it is determined that the access from the object 1A to the object 1B is not permitted, the access request from the object 1A is rejected by the management system 3 (step 204a), and the object 1B is rejected by the unauthorized access. Be protected.

Here, since the access validity check in step 202a, that is, the processing 205a in FIG. 2 is performed by the management system 3 (internal security checker 3a) based on the access right list table 2, Unlike the case of the conventional processing procedure shown in FIG. 2 (b), it is not necessary to prepare each application program.

In the embodiment described above, the access validity check is performed by the management system. However, the validity check may be performed by the access request destination object. Therefore, a second embodiment in which the object of the access request destination is subjected to the validity check will be described with reference to the drawings. [Second Embodiment] FIG. 3 is a block diagram showing the second embodiment of the present invention. The same parts as those in FIG. 1 are designated by the same reference numerals.

In FIG. 3, 11A is an access request source object, and 11B is an access request destination object of the object 11A. Object 11B
When a request for access to the object 11B is made from an object of an access request source as a part of the procedure class 110, a check procedure for checking the validity of the access by referring to the access right list table 2 , Security inspection unit). The object 11A also has a similar security inspection unit for the case where the object 11A itself is the access request destination, but it is omitted in the figure.

An object-oriented database management system (OODBMS) 13 manages an object-oriented database (not shown) which stores an object group including the objects 11A and 11B.

In the configuration of FIG. 3, for example, when an access request from the object 11A to the object 11B occurs, the access validity check is performed by the access request destination object 11B (not the management system 13). The configuration is almost the same as that of FIG. 1 except that it is performed by the security inspection unit 111).

That is, when an access request from the object 11A to the object 11B occurs, the message is passed to the object 11B via the management system (OODBMS) 13.

Upon receiving the message from the object 11A, the security checking unit 111 in the object 11B indicates from the access right list table 2 whether the access request source 2a is the object 11A and the access request destination 2b is the object 11B. Permission information 2
c is searched, and the validity of the requested access is checked based on the information 2c. If object 11A
If the access from the object to the object 11B is permitted, the accessed process in the object 11B according to the message from the object 11A is performed. On the other hand, if access from the object 11A to the object 11B is not permitted, the object 1
The access request from 1A is rejected by the object 11B, and the object 11B is protected from unauthorized access.

The access validity check in this embodiment is based on the access right list table 2 and is the object 11B of the access request destination (the security checker 11 in the object 11B).
Since it is performed by 1), it is not necessary to prepare for each application.

In the first and second embodiments described above,
Although the table (2) holding the access permission / denial information (2c) used for the access validity check is provided, instead of the table, the access right description information describing the access right between objects is stored in the object. It may be provided as (a part of) the attribute to have, and the access validity check may be performed on the object having the information. Therefore, the third embodiment and the fourth embodiment in which the validity check is performed by the specific object having the access right description information as (a part of) the attribute will be sequentially described with reference to the drawings. [Third Embodiment] FIG. 4 is a block diagram showing the third embodiment of the present invention. The same parts as those in FIG. 1 are designated by the same reference numerals.

In FIG. 4, 3'is an object-oriented database management system (OODBMS), and 4 is a specific object. This object 4 is an inspection procedure (hereinafter, referred to as a security inspection unit) that inspects the validity of the access when an access request from the access request source object to the access request destination object occurs as a part of the procedures 401. (Referred to as 402). The object 4 also describes, as a part of the attributes 403, access rights for all combinations of an arbitrary object that can be an access request source and an arbitrary object that can be an access request destination (access in FIG. 1 and FIG. 2). It has access right description information (corresponding to the right list table 2).

In the structure shown in FIG. 4, when an access request from the object 1A to the object 1B is generated, the management system (OODBMS) 3'will send an inquiry message to the object 4 as to whether or not the access is valid. Passed.

Then, in the object 4, the security inspection unit 402 (access request source object,
The access validity is checked based on the access request destination object and the access right description information 404, and the check result is returned to the inquiry source management system 3 '.

If the inspection result returned from the object 4 permits access from the object 1A to the object 1B, the management system 3'passes the message from the object 1A to the object 1B. As a result, the processing of the accessed object 1B (accessed processing) is performed according to the message from the object 1A. On the other hand, if the access from the object 1A to the object 1B is not permitted, the access request from the object 1A is rejected by the management system 3'and the object 1B is protected from unauthorized access. [Fourth Embodiment] FIG. 5 is a block diagram showing the fourth embodiment of the present invention. The same parts as those in FIG. 1 or 4 are designated by the same reference numerals.

In FIG. 5, 11A 'is the access request source object, and 11B' is the object 11A '.
Is the object of the access request destination of. This object 11B 'has a function of inquiring the object 4 as to whether or not the access is valid when the access request source object makes an access request to the object 11B'. Object 11
A ′ also has a similar inquiry function in the case where it becomes the access request destination.

In the configuration of FIG. 5, when an access request from the object 11A 'to the object 11B' occurs, the message is sent to the management system (OODB).
MS) 13 to object 11B '.

The object 11B 'is the object 1
When the message from 1A 'is received, the object 4
, An inquiry message as to whether or not the access is valid is passed.

Then, in the object 4, the security checking unit 402 (access request source object,
The access validity is checked based on the access request destination object and the access right description information 404, and the check result is returned to the inquiry source object 11B '.

According to the inspection result returned to the object 11B ', the objects 11A' to 11
Object 11 according to the message from object 11A 'if access to B'is permitted
The accessed process at B'is performed. On the other hand, if the access from the object 11A 'to the object 11B' is not permitted, the access request from the object 11A 'is rejected by the object 11B' and the object 11B 'is protected from unauthorized access.

In the first to fourth embodiments described above, the access right for accessing an object is
Access right list table 2 or access right description information 4
Although it is given to each object by 04, it may be given to each object group of an arbitrary unit.

In the first to fourth embodiments, the access request source object and the access request destination object are associated with the access right of the access request source object to the access request destination object, but the present invention is not limited to this. is not. For example, each object includes an object identifier (or object identifier group) of another object (or object group) to which the object has an access right, and is encrypted (encoded) data (hereinafter referred to as key data). When one object accesses another object, the key data is passed together with other arguments, and the access request destination object or management system (OODBM
It is also possible to input the key data in S) and check the validity of the access. Therefore, a fifth embodiment using this key data will be described with reference to the drawings. [Fifth Embodiment] FIG. 6 is a block diagram showing the fifth embodiment of the present invention.

In FIG. 6A, 21A is an access request source object, and 21B is the object 21A.
Is the object of the access request destination of. Each object 21i (i = A, B) is, as shown in FIG.
In addition to the well-known object identifier 211, procedures 212 and attributes 214, key data 215 is held as internal data protected from other objects. This key data 215 is a kind of encrypted (encoded) data including object identifiers (object identifiers) of other objects (objects) to which the object 21i has an access right (that is, access from the object 21i is permitted). Is. Also, in the procedures 212, when an access request is made from another object, the validity of the access is checked based on the key data (215) of the request source object and the object identifier (211) of the request destination object. It has an inspection procedure (hereinafter, referred to as a security inspection unit) 213 for performing the inspection.

Here, the key data 215 possessed by the object 21A is replaced with the key data 21 possessed by another object.
In order to distinguish it from 5, it will be called key data 21Ak. Next, the operation of the configuration of FIG. 6 will be described with reference to the flowchart of FIG. 7 when the access request from the object 21A to the object 21B occurs.

First, when an access request to the object 21B occurs and the object 21A accesses the object 21B, the object 21A passes its own key data 21Ak (215) to the object 21B together with an argument.

The object 21B is the object 21
When there is an access request from A (step 701), it is passed from the access request source object 11A for the access validity check in the accessed process (step 702) which is the process of the access side. The security checking unit 213, which is a part of the procedure 212 owned by itself, includes the key data 21Ak (215) and the information for specifying the object 21B itself (that is, the accessed object 21B itself), for example, the object identifier 211. Pass to.

The security checking unit 213 of the access request destination object 21B uses the key data 21Ak (215) from the request source object 11A and the object identifier 211 of itself (request destination object 21B) to generate the key data 21Ak (215). ), Whether or not access to the object 21B indicated by the object identifier 211 is permitted (that is, whether or not the request source object 21A is given the access right to the request destination object 21B) ( Step 703) is performed.

If the access from the object 21A to the object 21B is permitted, the actual accessed processing in the object 11B (step 70).
4) is performed. On the other hand, if the access from the object 21A to the object 21B is not permitted, the access request from the object 21A is rejected by the object 21B (step 705), and the object 21B is protected from unauthorized access.

Here, the access validity check in step 703, that is, the processing 706 in FIG. 7, is the processing of the accessed object (21B), that is, the procedure 212.
Because it is hidden as a part of, it enables high security and flexible response.

Incidentally, the management system (OODBMS) is provided with an inspection means corresponding to the security inspection unit 213,
The access validity check in step 703 may be performed by the management system (OODBMS) instead of the access request destination object (21B). This is the same in the following examples.

In the fifth embodiment, when one object accesses another object, the key data is passed, and based on the key data (and the object identifier of the object to be accessed), the access is authorized. This is a description of security management that performs a sex check.

As described above, in the fifth embodiment, the key data of the access request source object is used to check the validity of access to the request destination object that is directly accessed from the request source object. From the second object if access to the third object (which the second object does not have access to) is included as part of the processing requested by the first object for the second object. The validity check of access to the third object is performed using the key data passed from the first object (original request source) instead of the key data of the second object (direct request source). It is also possible to do so. Therefore, a sixth embodiment to which such an access validity check is applied will be described with reference to the drawings. [Sixth Embodiment] FIG. 8 is a block diagram showing the sixth embodiment of the present invention.

In FIG. 8A, 31A to 31C are objects. Here, it is assumed that the object 31A has an access right to the object 31B and is an access request source of the object 31B. Also, the objects 31A to 31B
It is assumed that access to the object 31C from the object 31B is included as a part of the processing requested to the. Therefore, the object 31B is the access request source of the object 31C. However, the object 31B does not have the access right to the object 31C.

The basic structure of the objects 31A to 31C is the same as that of the object 21i shown in FIG. For example, the objects 31A and 31B are as shown in FIG.
As shown in (c), the object identifiers 311A, 311A, 3
11B, procedures 312A and 312B, attributes 314
A, 314B and key data 315A (31Ak), 3
It has 15B (31Bk).

In this embodiment, a process "31B.func2 (argument, 31Ak)" for accessing the object 31B is prepared as a part of the procedure (process) 312A of the object 31A.

Here, the description portion in parentheses attached to func2 designates an argument passed to the process (func2) in the object 31B called from the object 31A. In the above example, the object 31B is requested. The original argument used for the process and the key data (here, 31Ak which is the key data 315A of the object 31A) are designated.

Therefore, in the object 31A, the access process "31B.func2 (argument, 31A
k) ”occurs, the corresponding object 31A
31Ak that is the key data 315A of the above is passed to the object 31B together with the argument.

In this case, for example, by the security inspection unit (corresponding to the security inspection unit 213 in FIG. 6) in the procedure 312B of the object 31B, the key data 315A of the object 31A and the object 31A.
Based on the B object identifier 311B, the validity of access to the object 31B is checked. Here, since the object 31A has the access right to the object 31B, the validity of the access is determined, and the accessed process is performed in the object 31B.

Further, in this embodiment, as a part of the procedure (process) 312B of the object 31B when accessed by the object 31A, the process "31C.func3 (argument, aKe) for accessing the object 31C is performed.
y) ”is prepared. That is, the process of accessing the object 31C as a part of the process requested by the object 31A of the object 31B“ 31C. func3
(Argument, aKey) ”is included.

Here, the description part in parentheses attached to func3 designates an argument passed to the process (func3) in the object 31C called from the object 31B. In the above example, the object 31C is requested. Original argument used for processing and object 3
The key data “aKey” passed from 1B (here, 31A which is the key data 315A of the object 31A).
k) and are specified.

Therefore, the process "31C.func3"
In accessing the object 31C according to (argument, aKey) ", that is, from the object 31A to the process" 31B. By accessing the object 31B according to "func2 (argument, 31Ak)", when the object 31B further accesses the object 31C, not the key data 315B (31Bk) of its own, but a part of ( “AKey” (here, 31Ak which is the key data 315A of the object 31A) passed as “aKey” is a process of accessing the object 31C “31C. func3 (argument, aKe
y) ”as an argument (part of)
Passed to C.

In the object 31C, the security check unit (corresponding to the security check unit 213 in FIG. 6) prepared in the procedure class performs the process "31C.
"aKey" passed from the object 31B according to "func3 (argument, aKey)", that is, object 3
Based on 31Ak that is the key data 315A of 1A and the object identifier of the object 31C, the access validity check is performed.

As a result, for example, the object 31A reflects the user's access right, and the object 31A
Assuming that B is an object that accesses a certain database (object 31C), the data of that object 31C is stored in the object 3 only within the authority of the user.
The process of not accessing 1A can be easily realized.

As described above, in this embodiment, when the object 31A has the access right to the object 31B and the access to the object 31C is included as a part of the processing requested by the object 31A to the object 31B, By specifying the key data of the object 31A given from the object 31A when the object 31B accesses the object 31C in the processing, even if the object 31B does not have the access right to the object 31C originally, 31C of the object 31A that is the request source of
Access right to the object 31C determines the validity of access to the object 31C.

In the case where access to the third object (which the first object does not have access right to) is included as part of the processing requested by the first object to the second object, Different from the sixth embodiment, the validity check of the access from the second object to the third object is performed by using the key data of the second object (direct request source). Is also possible. Therefore, a seventh embodiment to which such an access validity check is applied will be described with reference to the drawings. [Seventh Embodiment] FIG. 9 is a block diagram showing the seventh embodiment of the present invention.

In FIG. 9A, 41A to 41C are objects. Here, it is assumed that the object 41A has an access right to the object 41B and is an access request source of the object 41B. Also, the objects 41A to 41B
It is assumed that access from the object 41B to the object 41C is included as a part of the processing requested to the. Therefore, the object 41B is the access request source of the object 41C. Further, the object 41B has the access right to the object 41C, but the object 41A
Suppose you do not have access to C.

The basic structure of the objects 41A to 41C is the same as that of the object 21i shown in FIG. For example, the objects 41A and 41B are as shown in FIG.
As shown in (c), the object identifiers 411A, 4
11B, procedures 412A, 412B, attributes 414
A, 414B and key data 415A (41Ak), 4
It has 15B (41Bk).

In the present embodiment, as a part of the procedure (process) 412A of the object 41A, a process "41B.func2 (argument, 41Ak)" for accessing the object 41B is prepared.

Therefore, in the object 41A, this access processing "41B.func2 (argument, 4
1Ak) ”occurs, the corresponding object 4
41Ak which is the key data 415A of 1A is passed to the object 41B together with the argument.

In this case, for example, from the security inspection section (corresponding to the security inspection section 213 in FIG. 6) in the procedures 412B of the object 41B, the key data 415A and the object 41B of the object 41A are input.
The validity of access to the object 41B is checked based on the object identifier 511B. Here, since the object 41A has the access right to the object 41B, the validity of the access is determined, and the accessed processing is performed in the object 41B.

Further, in this embodiment, as a part of the procedure (process) 412B of the object 41B when accessed by the object 41A, the process "41C.func3 (argument, 41B) for accessing the object 41C is performed.
k) ”is prepared. That is, the process of accessing the object 41C as a part of the process requested by the object 41A to the object 41B“ 41C. func3
(Argument, 41Bk) "is included.

This process "41C.func3 (argument, 4
1Bk) ", the object 41C is accessed, that is, the process from the object 41A to" 41B. f
unc2 (argument, 41Ak) ”according to object 4
By accessing 1B, the object 4
When 1B further accesses the object 41C,
(When accessing the object 41A from the object 41A, not the key data passed from the object 41A), the key data 415B (41
Bk) processing for accessing the object 41C “4
1C. It is passed to this object 41C as an argument (part of) of "func3 (argument, 41Bk)".

In the object 41C, the security check unit (corresponding to the security check unit 213 in FIG. 6) prepared in the procedure group performs the process "41C.
Based on the key data 415B (41Bk) (of the object 41B) passed from the object 41B according to "func3 (argument, 41Bk)" and the object identifier of the object 41C, the access validity check is performed.

Thus, for example, the object 41B is an object (41C-1, 41C) which is a large number of constituent elements.
-2, ...) By simply granting the access right to the object 41B to the object 41A, it is possible to easily realize access to all the objects that are the constituent elements of the object 41B.

In addition, both access controls (security management) in the sixth and seventh embodiments can be realized at the same time. Therefore, an eighth embodiment for realizing such a security management function will be described with reference to the drawings. [Eighth Embodiment] FIG. 10 is a block diagram showing the eighth embodiment of the present invention.

In FIG. 10A, 51A to 51C are objects. Here, it is assumed that the object 51A has an access right to the object 51B and the object 51C and is an access request source of the object 51B. Further, it is assumed that access from the object 51B to the object 51C is included as part of the processing requested from the object 51A to the object 51B. Therefore, the object 51B is the access request source of the object 51C.

The basic structure of the objects 51A to 51C is the same as that of the object 21i shown in FIG. For example, the objects 51A and 51B are as shown in FIG.
As shown in (c), the object identifiers 511A, 5
11B, procedures 512A, 512B, attributes 514
A, 514B and key data 515A (51Ak), 5
It has 15B (51Bk).

In this embodiment, a process "51B.func2 (argument, 51Ak)" for accessing the object 51B is prepared as a part of the procedure (process) 512A of the object 51A.

Therefore, in the object 51A, this access processing "51B.func2 (argument, 5
1Ak) ”occurs, the corresponding object 5
51Ak which is the key data 515A of 1A is passed to the object 51B together with the argument.

In this case, for example, from the security inspection section (corresponding to the security inspection section 213 in FIG. 6) in the procedure 512B of the object 51B, the key data 515A and the object 51B of the object 51A are obtained.
The validity of access to the object 51B is checked based on the object identifier 511B. Here, since the object 51A has the access right to the object 51B, the legitimacy of the access is determined, and the accessed processing in the object 51B is performed.

Further, in this embodiment, as a part of the procedure (process) 512B of the object 51B when accessed by the object 51A, the process "51C.func3 (argument, key) for accessing the object 51C is performed.
Bind (aKey, 51Bk)) "is prepared.

Here, the description portion in parentheses attached to func3 designates an argument passed to the process (func3) in the object 51C called from the object 51B. In the above example, the object 51C is requested. The original arguments used for processing and the above processing (fu
nc2) is passed as an argument of "aKey" (here, 5 which is the key data 515A of the object 51A).
1Ak) and its own key data 515B, 51Bk, are combined to create new key data “keyBind (aKey
y, 51 Bk) ”is designated.

Therefore, the procedures (processing) of the object 51B when accessed by the object 51A
As a part of 512B, two key data key1, k
ey2 (here, key1 = aKey = 51Ak, k
There is also provided a process “keyBind” for generating new key data by concatenating ey2 == 51Bk).

Therefore, the above-mentioned processing "51C.func3 (argument, keyBind) in the object 51B is performed.
Object 51C according to (aKey, 51Bk)) "
When the object 51B further accesses the object 51C, that is, when the object 51B is further accessed by the object 51A according to the process “51B.func2 (argument, 51Ak)” from the object 51A. "AKey" (here, 51Ak which is the key data 515A of the object 51A) and itself (the object 51
51Bk which is the key data 515B in B) is processed by "k".
new key data “aKey + 51Bk” (here, “51Ak + 51B” is connected by using “eyBind”).
k ") is generated, and this new key data is used as a process" 51C.
func3 (argument, keyBind (aKey, 51B
k)) ”as an (part of) this object 5
Passed to 1C.

In the object 51C, the security check unit (corresponding to the security check unit 213 in FIG. 6) prepared in the procedure class performs the process "51C.
func3 (argument, keyBind (aKey, 51B
k)) ”according to the key data passed from the object 51B (51Ak which is the key data 515A of the object 51A and the key data 515B of the object 51B).
The key data which is the connection of 51Bk) "aKey + 5
Based on 1Bk ”(=“ 51Ak + 51Bk ”) and the object identifier of the object 51C, this key data“ aKey + 51Bk ”(=“ 51Ak + 51B ”
k ″), the access validity check is performed to determine whether or not access to the object 51C indicated by the object identifier is permitted.

As a result, the access control (security management) described in the sixth and seventh embodiments can be realized at the same time. In the above description, to simplify the explanation, there is one type of access right, and if an object has an access right to another object, it is possible to access regardless of the access type. However, it is not limited to this. For example, an access right may be set (granted) for each type of access such as reference and update. That is, the concept of an access right mode in consideration of the type of access is introduced, and the access request source object and the access are accessed from the table corresponding to the access right list table 2 (or the access right description information corresponding to the access right description information 404). The request destination object is made to correspond to the access right mode of the access request source object to the access request destination object, or each object is made to hold key data describing the correspondence between the access right mode and the target object. Good.

[0096]

As described above in detail, according to the present invention, it is possible to check whether access to an object is valid by adding data which means an access right when accessing the object. As a result, the load on the application programmer can be reduced and finer access control can be performed.

[Brief description of drawings]

FIG. 1 is a block configuration diagram showing a first embodiment of the present invention.

FIG. 2 is a diagram showing an operation of the first embodiment in comparison with a conventional one, and FIG. 2 (a) is a processing procedure when an access request from an object 1A to an object 1B occurs in the configuration of FIG. 2 is a flowchart showing
(B) is a flowchart showing a conventional processing procedure.

FIG. 3 is a block configuration diagram showing a second embodiment of the present invention.

FIG. 4 is a block diagram showing a third embodiment of the present invention.

FIG. 5 is a block diagram showing a fourth embodiment of the present invention.

FIG. 6 is a block configuration diagram showing a fifth embodiment of the present invention.

FIG. 7 shows an operation of the object 21A according to the fifth embodiment.
21 is a flowchart for explaining a case in which an access request to the object 21B is generated.

FIG. 8 is a block diagram showing a sixth embodiment of the present invention.

FIG. 9 is a block diagram showing a seventh embodiment of the present invention.

FIG. 10 is a block configuration diagram showing an eighth embodiment of the present invention.

[Explanation of symbols]

1A, 1B, 4, 11A, 11B, 11A ', 11
B ', 21A, 21B, 21i, 31A, 31B, 41
A, 41B, 51A, 51B ... Object, 2 ... Access right list table, 3, 3 ', 13 ... Object-oriented database management system (OODBMS), 3a,
111, 213, 402 ... Security inspection unit, 11
0,212,312A, 312B, 401,412A,
412B, 512A, 512B ... procedures, 214, 3
14A, 314B, 403, 414A, 414B, 51
4A, 514B ... Attributes, 404 ... Access right description information, 211, 311A, 311B, 411A, 411
B, 511A, 511B ... Object identifier, 21
5,315A, 315B, 415A, 415B, 515
A, 515B ... Key data.

Claims (5)

[Claims] 1. A security management method for an object-oriented database that stores a group of objects representing data, wherein each object on the object-oriented database is associated with an access right from that object to another object or a group of objects. Management information is prepared, and when an access request from one object on the object-oriented database to another object occurs, the validity of the access is checked according to the management information. A security management method for object-oriented databases. 2. A security management method for an object-oriented database that stores a group of objects representing data, wherein each object on the object-oriented database is provided with another object or a group of objects to which the object has access rights. Having the key data that is the represented data, when accessing another object from one object on the object-oriented database, outputs the key data that it has with an argument for the requested process, By the object-oriented database management system for managing the object-oriented database or a part of the procedures of the access request destination object, the key data from the access request source object and the access request destination object A security management method for an object-oriented database, characterized in that the validity of access to the access request destination object indicated by the value is checked based on the value that identifies the object. 3. The object group stored in the object-oriented database includes first to third objects, and the first object has access right to at least the second object. The second object has a specific process for accessing the third object as a part of the processing procedure when the second object is accessed by the first object. When the third object is accessed from the second object according to the specific processing, by specifying the specific key data output from the first object, The legitimacy of access to the third object is a request for access to the second object. Security management method of object-oriented database according to claim 2, characterized in that so as to check on the basis of the key data of the first object. 4. The object group stored in the object-oriented database includes first to third objects, and the first object has access right to at least the second object. Having a first key data indicating that the second object has a specific process of accessing the third object as a part of a processing procedure when accessed from the first object, and In the case of having at least second key data indicating that the third object has an access right to the third object, when the third object is accessed from the second object according to the specific processing, By designating the second key data, the second object can be accessed from the first object. The legitimacy of the access from the second object to the third object performed as a part of the processing procedure at the time of access is checked based on the second key data of the second object. The security management method for an object-oriented database according to claim 2, characterized in that. 5. The object group stored in the object-oriented database includes first to third objects, and the first object has access right to at least the second object. Indicating that the second object has a specific process for accessing the third object as a part of a processing procedure when the second object is accessed by the first object, and When the second object has the second key data and the third object is accessed from the second object according to the specific process, the first key data output from the first object and the first key data The new key data is generated by linking the second key data of the second object with the new key data. -By specifying the data, the validity of the access from the second object to the third object performed as a part of the processing procedure when the first object accesses the second object is confirmed. , The inspection is performed based on new key data in which the first key data of the first object and the second key data of the second object are connected. Item 2. An object-oriented database security management method according to item 2.