Method and system for enhancing quorum based access control to a database

[0002] The present invention relates generally to computer software, and more particularly, to a system and method for implementing a quorum based access control mechanism for modifying a database component.

[0003] In today's computer network environment, it is common that significant amounts of data are customarily stored and used by various users of a database. Naturally, data management has become an essential task for many data intensive industries. A smooth business operation relies both on the efficiency and security of the database. With the advancement of computer technologies, the size and complexity of a typical database is increasing continuously.

[0004] Different users of the database normally have different levels of access rights. From the perspective of data management, a database administrator (DBA) is powerful in that he usually has a full access to the entire database and all data stored therein. He can freely read, write and modify any data stored in the database. In a normal situation, the DBA is endowed with the highest level of trust because of his important responsibilities. Other users may be given different access rights depending on their needs. Some have read access rights only, while others have write access rights. Under certain circumstances, it is desirable to store data in a database in a secure way such that even a privileged user like the DBA should not be able to modify records of the database without being detected or without obtaining consents from some other database managers such as an independent auditor. The role of an independent auditor is to trace any user's , including the DBA's , actions relating to the database, thereby enhancing the integrity and the security of the database.

[0005] From the inception of the concept of computer databases, the access control issue of a database focuses on access rights of a single user. The scope of access belonging to a particular user depends exclusively on the access rights granted to him by a superior authority, who may very likely be the DBA. For example, in a normal case, a user who has a write access right to a database attribute can modify that attribute freely. However, those who have only an access right to read the same attribute can not “touch” the attribute.

[0006] With the database security problem becoming an increasingly complex and sensitive issue for operation on a daily basis, there is a growing need to support quorum based modifications in a database. There are situations when not a single user can be trusted to take actions alone in the database, and such situations warrant the need of a quorum based access control mechanism. In these situations, a minimum of two authorized users must together initiate a change to the database, and the number of the users required can be changed by a superior user of the database depending on the need of a particular case.

[0007] For instance, a network audit configuration is stored in a Novell proprietary Network Directory Service (the “NDS”) in the form of Audit Policy objects. The access control to these objects is managed by the NDS. In a typical scenario, there are at least two high-level trusted users involved, e.g., a DBA (or a system administrator of the same capacity) and a “top level auditor.” Unfortunately, neither of them trusts, or should trust, the other. Hence, any one of them is denied access to modify the network audit configuration (e.g., the audit policies) single-handedly. The check-and-balance relationship between the DBA and the auditor helps to enhance the database security, but nevertheless hinders some of the database operations. There are situations when any of them needs an access to the audit policy objects. For instance, some changes in the organization's security policies may need to be modified. However, it is not desirable that any one of them should be able to modify the audit policy objects or even modify an Access Control List (which enables him to modify the objects) without the knowledge of the other. A clear consent of both the DBA and the auditor is required for the modification to occur.

[0008] What is needed is an efficient method for implementing a quorum based access control mechanism for modifying a database.

[0009] A method and system is provided for implementing a quorum based access control mechanism for modifying at least one value of a database component (“Database Attribute”). In a typical example, the database is managed by a network directory service. Upon a request of an initiator who has a special right, the network directory service establishes one or more quorum attributes for defining the quorum based access control mechanism.

[0010] Once the quorum attributes are established, the quorum attributes provide one or more authorized users who have rights to participate in a quorum for accepting or rejecting a modification request. According to one example, various quorum attributes clearly define the access control mechanism. For instance, a Modified Attribute Value is for temporarily storing a proposed value for modifying the Database Attribute. A List of Owners indicates a list of authorized users who have rights to consider the Modified Attribute Value. A Quorum Size attribute defines a minimum number of authorized users to form a quorum to accept the Modified Attribute Value. A time period is also provided by the quorum attribute to require the modification request to be considered within a predetermined time frame. A Mandatory Authorizers attribute provides a list of authorized users whose participation in the quorum are mandatory for modifying the Database Attribute with the Modified Attribute Value. The Mandatory Authorizers is a sub group of the List of Owners. Moreover, an Authorization Status Table records identities and actions taken by the authorized users in the List of Owners.

[0011] When a modifier initiates a modification request, he proposes a value to modify the Database Attribute. The modification request is granted and the Database Attribute is changed to the proposed value if a quorum, as defined by the quorum attributes, is reached and all of the Mandatory Authorizers have accepted the proposed value within the predetermined time frame.

[0012] FIG. 1 illustrates a directory schema designed to support a quorum based access control mechanism according to one example of the present invention.

[0013] FIG. 2 is a flow diagram illustrating key processes for a user having a special access right to the directory schema to set up a quorum based access control mechanism for modifying a database component.

[0014] FIG. 3 is a flow diagram illustrating processes for any authorized user or owner to propose a modification of a database component according to one example of the present invention.

[0015] FIG. 4 is a flow diagram illustrating a Validation and Update Process shown in FIG. 3 conducted by a Network Directory Service.

[0016] FIG. 5 illustrates a computer system for implementing the present invention.

[0017] Referring now to FIG. 1, a directory schema 10 designed to implement a quorum based access control mechanism is shown according to one example of the present invention. A database, or any component of the database such as a database directory, is provided and defined with a series of attributes (“quorum attributes”). Since the database component is subjected to modifications by one or more authorized users or owners simultaneously (or “quorum based modifications”), the quorum attributes in aggregate define access rights of the users. In one example, the quorum attributes include Modified Attribute Value 12, List of Owners 14, Modifier 16, Quorum Size 18, Modification Request Time 20, End Time 22, Mandatory Authorizers 24, and Authorization Status Table 26. Details for defining these attributes are explained further below.

[0018] This quorum attribute should be able to hold a suggested or proposed value for a database component whose access has to be controlled by a quorum. That is, a minimum number of the authorized users must all agree to the proposed value before the value of the database component (“Database Attribute”) can actually be changed. This quorum attribute thus serves the purpose of a “buffer” parameter that can be modified without changing the original or actual value of the database component. Only when a legitimate quorum has been obtained to accept a proposed value, then the Database Attribute will be replaced.

[0019] This is a set of authorized users or owners of the Database Attribute among whom a quorum is necessary for modifying the Database Attribute. In terms of computer language for databases, this quorum attribute can be of a type FDN[ ] containing multiple parameters of Fully Distinguished Name (FDN) type.

[0020] This quorum attribute lists an authorized user or owner who initially suggests the modification of the Database Attribute. It may also be of a FDN type. If one is included in the List of Owners, he can be a Modifier at any time.

[0021] This quorum attribute records the time at which an initial modification request is made by the modifier.

[0022] This quorum attribute defines a time deadline by which other authorized users and owners in the List of Owners must respond to effect the modification. If a quorum is not reached by this time, the database (or the NDS) resets all relevant fields and no change of the Database Attribute will take place.

[0023] This quorum attribute is a subset of the List of Owners whose authorizations are mandatory for the modification of the Database Attribute to occur. Absent an approval from any one of the mandatory authorizers, any attempt to modify the Database Attribute will fail. Hence, each of these users or owners listed has a “veto power” to prohibit any proposed changes. If this quorum attribute is set to be empty, the proposed modification is to be effected after a minimum number of approvals among any of the owners in the List of Owners (or a quorum) are cast (or a quorum is reached).

[0024] Quorum Size

[0025] This quorum attribute defines the size of a quorum required. It provides a minimum number of authorizations or approvals required among the authorized users or owners in the List of Owners to effect a suggested modification. This number must be greater than (or equal to) the size of the list of Mandatory Authorizers.

[0026] This table contains the status of authorizations given by various authorized users or owners between the Modification Request Time and End Time. The Authorization Status Table is a composite attribute and can be represented, as an example, using the following computer codes in C language:

[0027] wherein the “fdn” in the above code is the FDN of the owner who has authorized the modification and the “authorization Value” is a boolean attribute indicating acceptance (TRUE) or rejection (FALSE) of the corresponding owner.

[0028] When the owner requests a modification of a Database Attribute, he is now identified as the modifier, and the fdn field of the authorization Status Table is populated with the modifier's fdn and the authorization Value is set to TRUE. As and when other authorized owners or users accept or reject the modification request, corresponding information is recorded in the table.

[0029] There are certain inherent constraints of the quorum attributes, which are shared by all the quorum attributes, that define their relations among them. For example, the modifier must be one user listed in the List of Owners, the End Time is always greater than the Modification Request Time. Users listed in the Mandatory Authorizers must be included in the List of Owners, and the size of the Mandatory Authorizers is smaller than or equal to the Quorum Size. In addition, none of the authorized user has a right to write directly to the original Database Attribute, but each has read/write access rights on the Modified Attribute Value to begin with. Once a modifier has placed a request for modification, the write access right on the Modified Attribute Value granted to all other co-owners in the List of Owners are revoked till either the modification is effected, or rejected, or the modification request expires at the End Time. It is further understood that a Database Attribute can be a single attribute of a database component, a group of attributes of a database component, or a database component itself, or any other equivalents.

[0030] Referring now to FIG. 2, a flow diagram 30 illustrates key processes for a user having a special access right to the directory schema to set up a quorum based access control mechanism for modifying a Database Attribute. In step 32, a user having a special access to the Database Attribute (e.g., one who has a Supervisory right) authenticates to the Network Directory Service (NDS). The Supervisory right is a temporary right granted to a special user solely for the purpose of establishing the quorum based access control mechanism. Many standards or mechanisms can be established to determine who should have the Supervisory right and when he should have it. The user having the Supervisory right is deemed as an initiator who then issues a request to the NDS in step 34. In one example of the present invention, the request typically contains the following information:

[0031] List of Owners

[0032] List of Mandatory Authorizers, if any; and

[0033] Quorum Size, i.e. minimum authorizations of the owners required.

[0034] After receiving the request from the initiator, in step 36, the NDS creates all relevant quorum attributes such as those shown and described according to FIG. 1. The values of these quorum attributes are populated if possible in conformance with the content of the request sent by the initiator. Further in step 38, the NDS grants read access right to all owners to the Database Attribute. The NDS also grants read/write access rights to all owners to at least two attributes, e.g., the Modified Attribute Value attribute and End Time. This allows any member of the List of Owners to propose a change of the Database Attribute. Once appropriate access rights have been granted to the members of the List of Owners, the Supervisory right of the initiator is revoked in step 40. The write access rights of the initiator as to the Database Attribute, List of Owners, List of Mandatory Authorizers and Quorum Size are subsequently revoked. Consequently, none of the authorized users or owners is granted with the write access right to the Database Attribute. This assures that no one can change the Database Attribute without going through the quorum based access control mechanism. With the above described initiation processes, any proposed change to the Database Attribute will be examined and is subject to a quorum approval.

[0035] Referring now to FIG. 3, a flow diagram 50 illustrates processes for any authorized user or owner to propose a modification of a Database Attribute after the quorum based access control mechanism is established. A member of the List of Owners who desires to issue a Modification Request (“modifier”) must first authenticate to the NDS in step 52. He requests the modification of the Database Attribute by providing at least the following information to the NDS:

[0036] Proposed new value of the Database Attribute; and

[0037] End Time.

[0038] This can be done by sending a database message to the NDS. In order to process one proposed value at a time, in step 54, the NDS updates the value of the Modified Attribute Value and End Time, and then revokes the write access rights of all other co-owners to these two quorum attributes. The NDS also updates the Authorization Status Table to indicate the Modifier and his acceptance (i.e. inserting a value of TRUE to the corresponding parameter). The NDS populates the “Modification Request Time” attribute with the current time. In step 56, the NDS start to conduct a Validation and Update Process (described below later). The NDS registers the End Time with a scheduler which may be an external timer process for the database. In case the End Time is reached, the scheduler will terminate NDS's Validation and Update Process, and subsequently resets the Modification Request. In step 58, the modifier notifies all the owners about the modification request and solicits their approvals.

[0039] FIG. 4 is a flow diagram 60 illustrating the Validation and Update Process (step 56 in FIG. 3) conducted by the NDS according to one example of the present invention. After the Validation and Update Process is invoked, the Mandatory Authorizers attribute is checked in step 62 to determine whether it is empty or not. If it is empty, there is no owner who has a veto power to this particular Database Attribute. If the Mandatory Authorizers is not empty, then the Authorizer Status Table may need to be checked in step 64 to see whether all the mandatory authorizers have given their acceptances to the proposed value of the Database Attribute.

[0040] In the case where not all of the acceptances are given, step 66 determines whether any of the mandatory authorizers has declined to take position in the proposed change. If there is at least one mandatory authorizer who has declined, it is clear that he has exercised the veto power, and step 68 is conducted to reset the modification request and de-register the external scheduler. That is, the attempt to modify the Database Attribute is denied. Another outcome of step 64 is that all of the mandatory authorizers have given their acceptances. If so, step 70 decides whether a legitimate quorum has been reached. Only when a quorum has successfully been reached, the Database Attribute is permitted to change to the proposed value in step 72. After the value of the Database Attribute has been changed, step 68 is performed as well to conclude that a new value of the Database Attribute has been established and the modification request should be terminated.

[0041] After a modifier proposes a new value for the Database Attribute, in order to accept or reject a proposed modification request, an owner (or, more precisely, a co-owner) in the List of Owners first authenticates to the NDS. He then issues a message to the NDS indicating his acceptance or declination to the modification request. The NDS then updates the Authorization Status Table with information about the modifier and the parameter value indicating his acceptance (e.g., TRUE), or declination (e.g., FALSE).

[0042] It will also be understood by those having skill in the art that one or more (including all) of the elements/steps of the present invention may be implemented using software executed on a general purpose computer system or networked computer systems, using special purpose hardware-based computer systems, or using combinations of special purpose hardware and software. Referring now to FIG. 5, for the sake of example, a typical computer system 100 includes a two-dimensional graphical display (also referred to as a “screen”) 102 and a central processing unit 104. The central processing unit 104 contains a microprocessor and random access memory for storing programs. A disk drive 106 for loading programs may also be provided. A keyboard 108 having a plurality of keys thereon is connected to the central processing unit 104, and a pointing device such as a mouse 110 is also connected to the central processing unit 104.

[0043] The above disclosure provides many different embodiments, or examples, for implementing different features of the invention. Specific examples of components, and processes are described to help clarify the invention. These are, of course, merely examples, and are not intended to limit the invention from that described in the claims.

[0044] While the invention has been particularly shown and described with reference to the preferred embodiment thereof, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention, as set forth in the following claims.