JP2007041829A - Database authority management system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To facilitate management and operation by using authority managing methods and authority authenticating methods of a different types of database management systems in common. <P>SOLUTION: This database authority management system is provided with a database group 3 composed of a plurality of types of databases, a client 1 having an authentication requesting part 11 for making an operator input user identification information 4 and operation information 5 to request an authorized operation, and an authority management server 2 provided with an authenticating part 22 for comparing the user identification information 4 with an authentication information 21 to authenticate a user, a determining part 24 for determining authorized operation contents from the authorized operation information 5 and authority information 23, and a database operating part 26 for connecting to the databases to execute an access authority operation, wherein the authenticating part 22 can execute a database operation only when the user identification information 51 coincides with the authentication information 21, the determining part 24 extracts an authorized operation of an execution object from the authority information 23, and the database operating part 26 provides or cancel database authority. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a database authority management system.

  In general, a database system has a function that allows execution of processing for each type of data operation, objects to be operated, and their combination conditions. Only the minimum necessary authority is given to the user, depending on the user's role. Some of them increase the safety of data by limiting the operation range. According to this method, the user can use the authority previously given by the database administrator when the login is successful by the login authentication to the database.

  Further, it is known that a database has an authority authentication function in which an authority given in advance is not validated at the time of login, and an authority authentication different from the login authentication is required to validate. According to this method, since the authority cannot be exercised only by the login authentication, it is effective in improving the security of the database.

JP 2002-163260 A

  However, conventionally, the authority authentication function differs for each database, and in particular, a database without an authority authentication function cannot use the authority authentication function. For this reason, when attempting to operate these multiple types of databases, the authority procedure cannot be standardized for authority authentication, and authority management and authority authentication methods must be changed in consideration of database functional differences. In addition, there is a problem that the user operation procedure is complicated.

  Furthermore, conventionally, since the authority of the database is always given to the user, there is no time restriction as long as the authentication is received even in the database having the authority authentication function as well as the database without the authority authentication function, for example, at night or on holidays The method for preventing unauthorized access was not considered. For this reason, there is a security problem that unauthorized access to the database can be easily performed in the absence of the database administrator or the security administrator, or the discovery is delayed when the unauthorized access is successful.

  Accordingly, a first object of the present invention is to enable a database having no authority authentication function to perform authority authentication without changing the function of the database, and to share authority management methods and authority authentication methods for different types of databases. The present invention provides a database authority management system that is easy to manage and operate.

  In addition, a second object of the present invention is to determine a schedule for permitting and revoking authority in advance, and not to grant authority outside the permitted schedule, thereby improving database authority with improved security. It is to provide a management system.

  A third object of the present invention is to determine a schedule for granting and revoking authority in advance, automatically granting and revoking authority according to the schedule, and not giving authority outside the permitted schedule. And providing a database authority management system with improved security and operability.

  The present invention is characterized in that the authority management server makes the authority operation methods for different types of databases common by operating the authority of the database group from the outside in an integrated manner.

  Further, the present invention includes an authority operation including authority information including a schedule information for which an authority operation has been created in advance, and an authority operation request from the client. It is characterized by restricting outside authority operations.

  Furthermore, the present invention is characterized in that the authentication unit automatically executes granting or revoking of authority according to authority information including schedule information.

The database authority management system of the present invention makes it possible to use an authority authentication function without changing the database function for a database that does not have an authority authentication function, and can share operations with a database having an authority authentication function. Therefore, there is an advantage that authority management and authority authentication operation become easy.
In addition, the database authority management system of the present invention includes authority information including schedule information for which authority has been permitted that has been created in advance, and determines the authority operation request time from the client, thereby determining authority outside the permitted time. Since the operation can be restricted so that it cannot be performed, there is an advantage that the security of the database is improved.
In addition, the database authority management system of the present invention has the advantages of improving database security and operability by automating database authority operations according to the above-described schedule.

  The first object of the present invention is to enable authority authentication to a database having no authority authentication function without changing the function of the database, and to share the authority management method and authority authentication method for different types of databases. In order to realize the second object of the present invention, a schedule for granting and revoking authority is determined in advance, and authority is not given outside the permitted schedule. The authority operation of each database is centrally executed from an authority management server independent of the database group, and a determination unit that determines whether or not execution is possible according to a schedule is provided in the same server.

  Hereinafter, the configuration of the database authority management system according to the first embodiment of the present invention will be described with reference to FIGS.

  FIG. 1 is a block diagram of database authority management according to the first embodiment of the present invention. This database authority management system includes a client 1, an authority management server 2, and a database group 3. The database group 3 is composed of a plurality of different types of databases.

The client 1 allows the operator to input the user identification information 4 including the authentication ID 41 and the password 42, the authority operation information 5 including the operation type information 51, and the database identifier 52, and sends them to the authority management server 2 to transmit the authority management server 2. 2 is provided. In the present embodiment, it is assumed that the client 1 is the same computer as the database client having a client function for performing normal access to the database group 3, but may be realized on another apparatus.
The authentication ID 41 and password 42 of the user identification information 4 are for requesting authority assignment to the authority management server 2, and are different from the user ID and password for the user to log in to the database group 3. The operation type information 51 is information for instructing whether to grant or cancel the authority. In this embodiment, for example, “1” is given when giving an instruction, and “0” is given when giving a cancellation. The database identifier 52 is an identifier that identifies a database that is an object for which an operator requests an authority operation from the database group 3, and is determined so as not to be duplicated for each database.

  The authority management server 2 is a server device independent of the database 3 and includes authentication information 21, an authentication unit 22, authority information 23, a determination unit 24, login parameter information 25, and a database operation unit 26.

  FIG. 2 is a flowchart showing an outline of the operation of the authority management server 2. Hereinafter, the operation of the authority management server 2 will be described with reference to FIG.

  In step S100, the authentication unit 22 of the authority management server 2 is always on standby for receiving an authentication request from the client 1, and upon receiving an authentication request from the client authentication unit 11, the authentication ID 41, password 42, operation The type information 51 and the database identification information 52 are acquired.

  In step S101, the authentication unit 22 compares the authentication ID 41 and the password 42 acquired in step S100 with the authentication information 21 illustrated in FIG. As illustrated in FIG. 3, the authentication information 21 is a table including an authentication ID 21a and a password 21b, and needs to be created in advance by an authority manager. The authentication ID 21a should not be duplicated. The password 21b is encrypted and stored for security reasons, but is not particularly described for convenience of explanation.

  In step S102, the authentication result in the authentication unit 22 in step S101 is determined. That is, if the combination of the authentication ID 41 and the password 42 sent from the client exists in the authentication table 21, the authentication is successful, and if not, the authentication is unsuccessful. If the authentication fails, the database authority is not changed at all, the process is immediately terminated, and the process returns to the authentication request acceptance standby state in step S100. When the authentication is successful, among the acquired information, the authentication ID 41, the operation type information 51, and the database identification information 52 are passed from the authentication unit 22 to the determination unit 24.

  In step S <b> 103, the determination unit 24 reads the authority information 23 illustrated in FIG. 4 and extracts lines that meet the condition. As illustrated in FIG. 4, the authority information 23 is a table including columns of an authentication ID 23a, a DB identifier 23b, an operation type 23c, an SQL 23d, and an executable time 23e, and needs to be created in advance by an administrator. The SQL 23d column stores a standardized database operation language called SQL. What they mean is an operation to grant or revoke the appropriate authority. In the extraction of rows according to conditions, the authentication ID 41, the operation type information 51, and the database identification information 52 passed from the authentication unit 22 match the authentication ID 23a, the DB identifier 23b, and the operation type 23c of the authority / condition table 23, respectively. Made.

  In step S104, the determination unit 24 determines, for all lines, whether or not the executable schedule 23e of each line of the authority information 23 extracted in S103 is within the current date and time. For example, if the executable time is from 7:30 to 19:00 and the current time is 19:20, it is determined as a failure. For example, if the current time is 9:00 under the same conditions, it is determined to be successful. If it is determined to be successful, the extraction result in step S103 is passed to the database operation unit 26, and the process proceeds to step S105. If there is a failure in one line, the process is immediately stopped and the process returns to step S100. In this embodiment, if even one of the lines in the authority / condition table fails, the processing is immediately stopped and the process returns to step S100. However, only the successful line is passed to the database operation unit 26, You may make it progress to step S105. In this embodiment, the executable schedule information is only time information. However, the schedule information may include date information and day of the week information, and may be determined based on day of the week or holiday conditions, or a combination thereof. For example, the executable schedule for a certain authority is from 9: 00 to 17: 00 from Monday to Friday, from 13: 00 to 17: 00 on Saturday and Sunday, of which contents cannot be executed on specific holidays. It may be expressed. Also, the time during which execution is not permitted may be described as the execution prohibition time instead of the execution possible time. In this case, the determination part 24 determines with failure, when the present date is contained in the time which is not permitted.

  In step S <b> 105, the database operation unit 26 reads the login parameter information 25 and acquires login parameters for the database group 3. As illustrated in FIG. 5, the login parameter information 25 includes a DB identifier 25a, a URL 25b, a login user 25c, and a password 25d. The DB identifier 25a is used for comparison with the database identification information 52 input by the operator for identification. The URL 25 b is information necessary for accessing the authority management object database group 3. According to the present embodiment, the database operation unit 26 is implemented as a program that is written in a general programming language, logs into the database via a driver provided by the provider of the database group 3, and passes an SQL statement. In general, since the program interface of a driver is determined by the specification of the driver, the content described in the URL needs to be described according to the driver. The login user 25c and the password are authority management users created in advance on the database group 3 by the administrator of the database group 3. This authority management user needs to be given authority for logging in from the authority management server 2 and authority for granting and revoking authority in the database group 3. In general, the user creation method and the authorization method are different for each database. For example, in some databases, the right to log in is CREATE SESSION, and the right to grant and revoke is GRANT ANY PRIVILEGE or GRANT ANY OBJECT PRIVILEGE. In some databases, the database administrator or superuser There are things that need to be authorized to perform all operations on the database. These user creation methods and authority grant methods are disclosed in detail by database suppliers. These authorities need to be performed by each database administrator for each database to be operated.

  In step S106, using the URL, login user, and password acquired in step S105, the database operation unit 26 logs in to one database in the database group 3 as an authority management user.

  In step S107, the database operation unit 26 executes the execution target SQL sentence extracted in step S103. Specifically, it is realized by executing a process of passing an SQL statement to the database driver.

In step S108, the connection with the database generated in step S106 is disconnected.
In step S109, it is determined whether all authority operations have been completed. If all the processes are completed, the authority operation is terminated and the process returns to step S100. If there is still an SQL that has not been executed, the process returns to step S106, and processing is performed on another database in the database group 3. In this way, login, SQL execution, and logout are repeated until execution of all the SQL extracted by the determination unit 24 is completed.

  As described above, according to this embodiment, it is possible to perform authority authentication without adding a function to the database to a database without an authority authentication function, and by sharing an authority authentication method with a database having an authority authentication function. When operating a plurality of different types of databases, authority management and authority operation procedures can be facilitated.

  In the first embodiment, an example in which the authority management server grants or revokes authority using an authentication request by an operator as a trigger has been described. On the other hand, in the second embodiment, the case where the authority management server automatically adds or revokes the authority based on the schedule without adding an operator authentication request to the database authority management server of the first embodiment is described below. This will be described with reference to FIG. 1, FIG. 2, FIG. 4, FIG. 6, FIG.

  FIG. 6 is a diagram showing an example of authority information held by the authority management server according to the second embodiment of the present invention. The authority information of the first embodiment shown in FIG. 4 is further added with automatic execution flag information 23f. Become. The automatic execution flag information 23f indicates whether or not the corresponding authority operation is automatically executed according to the schedule, and is expressed as “1” when not automatically executed and “0” when not.

  FIG. 7 is a flowchart illustrating an example of an automatic execution operation added to the determination unit 23 according to the second embodiment. In addition to the operation S2 of the determination unit 24 corresponding to the authentication request from the operator in the first embodiment shown in FIG. 2, an automatic execution operation S4 of the determination unit that automatically executes the schedule is added. S4 operates asynchronously with the operation S2 of the determination unit 24 corresponding to the authentication request, and includes steps S200 and S201.

  In step 200, the schedule table 27 shown in FIG. 8 is created from the authority information of the second embodiment shown in FIG. According to this example, first, “1” is described in the automatic execution flag information 23 f on the first line and the fifth line of the authority information 23, and it can be determined that the target authority operation is an automatic execution. Next, the start time and end time of the target authority operation are specified from the executable time 23e, the authority granting operation at the start time, that is, the line whose operation type 23c is “1”, and the authority revoking operation at the end time That is, the line whose operation type 23c is “0” is selected. The schedule table 27 can be obtained by sorting the selected rows by time.

  In step 201, based on the schedule table 27 created in step 200, it is monitored whether or not the current time matches the automatic execution time 27c. That is, according to the example of the schedule table of FIG. 8, when the current time is 7:30, 9:00, 17:00, 19:00, the corresponding row is selected. The information on the selected row is transferred to the database operation unit 26, and the database operation unit 26 executes an authority operation.

  In the second embodiment, an example in which the authority operation by the authentication request from the client 1 and the automatic authority operation by the schedule are realized at the same time has been described. However, in order to realize only the automatic authority operation by the schedule more easily, the client 1 In this case, the client 1, the authentication information 21, and the authentication unit 22 are not provided, and the operation of the determination unit is the automatic schedule execution operation part, that is, 7 can be configured to include the S4 portion and not the S1 portion.

  According to the present embodiment, authority can be granted and revoked according to a predetermined schedule, and even if a user logs in to the database with an unauthorized schedule, operation is not possible because there is no authority, thus improving safety. A database authority management system can be provided.

It is a block diagram which shows one Embodiment of the database authority management system which concerns on this invention. Example 1 It is the flowchart which showed the operation example of the authority management server in the same embodiment. It is a table | surface which shows an example of the authentication information in the embodiment. It is a table | surface which shows an example of the authority information in the same embodiment. It is a table | surface which shows an example of the login parameter information in the embodiment. It is a table | surface which shows the authority management information in the database authority management system which concerns on this invention. (Example 2) It is a table | surface which shows a part of operation example of the determination part of the authority management server in the embodiment. It is a table | surface which shows an example of the schedule table which the determination part of the authority management server in the embodiment produces | generates.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Client apparatus 2 Authority management server 3 Database 4 User identification information 5 Authority operation information 11 Authentication request part 21 Authentication information 22 Authentication part 23 Authority information 24 Judgment part 25 Login parameter information 26 Database operation part 27 Schedule table

Claims (3)

A database group consisting of multiple types of databases,
A client having an authentication request unit for requesting an authority operation by allowing an operator to input user identification information and operation information;
An authentication unit that authenticates a user by comparing user identification information and authentication information, a determination unit that determines authority operation contents from authority operation information and authority information, and a database operation unit that connects to a database and executes an access authority operation With a privilege management server,
The authentication unit can execute the database operation only when the user identification information and the authentication information match, and the determination unit extracts the authority operation to be executed from the authority information based on the user identification information and the authority operation information. The database operation unit is configured to grant or revoke database authority using login parameter information in which login parameters for different types of databases are described.   The authority information further includes executable schedule information that defines a range of time or date that can be granted or revoked, and the determination unit compares the current date and time with the executable schedule information and is not in an executable range. 2. The database authority management system according to claim 1, wherein the authority database operation is not executed. The authority information further includes automatic execution flag information for instructing to automatically execute an authority operation based on the executable schedule information, and when the automatic execution flag information is a content for instructing automatic execution, the determination unit 3. The database authority management system according to claim 2, wherein according to the executable schedule, the database authority is granted or revoked based on the automatic execution date and time data when the database operation is performed.

Images