JP6755864B2 - Database security - Google Patents

Description

Priority Claim This application claims priority to US Provisional Patent Application No. 62 / 075,593 filed on November 5, 2014, all of which is by citation. Included herein.

Background This specification relates to database security. The database can contain multiple tables, and each of these tables can contain multiple rows. Access to the data records stored in the database can be controlled by controlling access to each of the tables or by controlling access to each row in the table. Row-level security can be provided through the use of security labels associated with each object, such as each row.

Overview In one aspect, the method includes the step of automatically determining the component of the security label for each first record in the first table of a database with multiple tables, which is based on a foreign key relationship. The step of identifying the second record related to one record, the step of identifying the component of the security label of the second record, and the component of the security label of the first record based on the identified component of the security label of the second record. Includes steps to assign the value of. The method involves storing the determined security label in a record.

Embodiments can include one or more of the following features:

The method is to identify multiple second records, each related to the first record, according to individual foreign key relationships, to identify the security label component for each of the second records, and to secure the second record. Includes a step of assigning the value of the security label component of the first record based on the value of each component of the identified components of the label.

The step of assigning the value of the security label component of the first record includes concatenating a plurality of distinct values of the identified component of the security label of the second record.

The step of assigning the value of the component of the security label is the step of identifying the highest priority value from the values of the identified component of the security label of the second record, and the step of assigning the highest priority value to the component of the security label of the first record. Includes steps to assign as the value of.

The method includes the step of automatically determining the component of the security label for each third record in the third table of the database based on the attributes of the record, where the attributes of the record are the values stored in the record. Is.

The method includes the step of automatically determining the security label component for each third record in the third table of the database based on the values associated with the third table.

The second record exists in a table other than the first table.

The component is the first component of the security label of the record, and the method comprises determining the second component of the security label.

The method comprises updating the security label component of a particular first record in response to a trigger event.

Trigger events include changes in foreign key relationships.

The trigger event includes a change in the security label component of the second record related to the particular first record.

The method includes a step of detecting a trigger event.

The method includes the step of receiving a notification of a trigger event.

The method comprises receiving an access request for a particular first record from the user, the user being associated with a user security code.

The method comprises restricting a user's access to a particular first record based on a comparison between the user's associated user security code component and the particular first record's security label component.

The method includes determining the security label of a record before receiving an access request.

The method includes the step of automatically determining the security label component of a particular first record when the first record is received for storage in the database.

In one aspect, the non-temporary computer-readable medium stores the instruction, which is a security label component for each first record in the first table of a database in which the arithmetic system has multiple tables. It is automatically determined and includes the step of identifying the second record related to the first record according to the external key relationship, the step of identifying the component of the security label of the second record, and the security label of the second record. A step of assigning the value of the component of the security label of the first record based on the identified component is included, and the determined security label is stored in the record.

In one aspect, the arithmetic system includes a memory-bound processor, which automatically determines the security label component for each first record in the first table of a database with multiple tables. Then, based on the step of identifying the second record related to the first record according to the foreign key relationship, the step of identifying the component of the security label of the second record, and the identified component of the security label of the second record. A step of assigning the value of the component of the security label of one record is included, and the determined security label is stored in the record.

In one aspect, the arithmetic system is a means of automatically determining the component of the security label for each first record in the first table of a database having a plurality of tables, and the first record is set according to the foreign key relationship. The step of identifying the second record involved, the step of identifying the component of the security label of the second record, and the assignment of the value of the component of the security label of the first record based on the identified component of the security label of the second record. A means including a step, and a means for storing the determined security label in the record.

In one aspect, the method is a step of determining that the first record stored in the first table of a database having a plurality of tables has been updated, and a step of automatically updating the first security label of the first record. The second record includes a step of storing the updated security label in the record and a step of automatically updating the second security label of the second record stored in the second table of the database. Is associated with the first record according to the foreign key relationship.

Embodiments can include one or more of the following features:

The method includes determining whether an update to the first record affects the first security label of the first record.

The method involves determining one or more components of the first security label that are affected by the update to the first record, and one or more components of the affected first security label. Includes steps to update automatically.

The second table is a child of the first table.

The method includes determining whether the update to the first record affects the foreign key relationship.

The method is to determine one or more foreign key relationships among the multiple foreign key relationships affected by the update to the first record, and each related to the first record according to the affected foreign key relationships. Includes a step of automatically updating the second security label for each second record.

In one aspect, the non-temporary computer-readable storage medium causes the arithmetic system to determine that the first record stored in the first table of the database having the plurality of tables has been updated, and the first record of the first record. 1 The security label is automatically updated, the updated security label is stored in the record, and the second security label of the second record stored in the second table of the database is automatically updated. The instruction is stored, and the second record is associated with the first record according to the foreign key relationship.

In one aspect, the arithmetic system includes a processor attached to memory, and the processor and memory determine that the first record stored in the first table of a database having a plurality of tables has been updated, and the first. The first security label of the record is automatically updated, the updated security label is stored in the record, and the second security label of the second record stored in the second table of the database is automatically updated. The second record is associated with the first record according to the foreign key relationship.

In one aspect, the arithmetic system automatically updates the means for determining that the first record stored in the first table of the database having a plurality of tables has been updated and the first security label of the first record. A means, a means for storing the updated security label in the record, and a means for automatically updating the second security label of the second record stored in the second table of the database are provided. The two records are associated with the first record according to the foreign key relationship.

Other features and advantages will become apparent from the following description and from the appended claims.

FIG. 1 is a block diagram. FIG. 2A is an example of a database system. FIG. 2B is an example of user access restriction. FIG. 3 is a block diagram. FIG. 4 is a block diagram. FIG. 5 is a flowchart. FIG. 6 is a flowchart. FIG. 7 is a flowchart. FIG. 8 is a flowchart. FIG. 9 is a block diagram.

Detailed Description In the present invention, the present inventors describe a method for providing row-level security for rows in a table of a database. Each row in the table represents a data record. A security label is stored within each row, which informs, for example, a user who has permission to access the data record represented by the row or a user who has restricted access to the data record represented by the row. It can be used to control access to a row, such as. The security label of a row in a table can be determined based on one or more of the information outside the row, the information inside the row, and the information specific to the table. Security label propagation, often referred to as inheritance, is a mechanism for determining a row's security label based at least in part on the security label of one or more related rows. For example, a row in a database table can inherit its security label component from another row in the same table or in another table that is associated with the row via a foreign key relationship. Security label inheritance helps ensure that users have restricted access to all other data records that depend on a given data record, for example, if the user has restricted access to a given data record. be able to.

A row security label can have multiple components. One or more of the security label components of a row in a table can be determined based on information outside the row, such as information in a related row in the same table or information in a related row in another table. it can. One or more of the components of a row's security label can be determined based on information inside the row, such as row attributes. One or more of the security label components of a row in a table can be determined based on information specific to the table, such as certain values associated with the table.

The security label of a data record (which we often use the terms row and data record in an interchangeable manner) can be determined as the data record is entered into the database. The security label of a data record can be updated in response to a trigger event such as a change in the data record, a change in the associated data record, or a change in information specific to the table. The security label is stored in the data record so that the security label has already been calculated and made available before any access request to the row is received. We often refer to this reception-independent security label operation as a security label pre-operation before receiving any access request to a row. Pre-calculation of security labels can have advantages. For example, if a row's security label is pre-calculated, determining if the user's access to the row is restricted is a computationally intensive process that calculates the security label in real time in response to an access request. Can be done quickly, without the need to do so.

The row-level security schemes described herein allow data to be protected within a database that has multiple interrelated tables. In such a database, the security label of a row in one table can be determined, at least in part, based on the security label of a row in another related table. For example, if a user's reference to a data record representing project finance is restricted, then the user's reference to the data record representing project finance is due to the relationship between the project summary and the data record representing project finance. Can be prevented automatically as well. If there are many rows in the database that need protection, but most of the security can be inferred from other related rows, then determining the security label based on these relationships can improve and maintain security. It can help reduce costs.

By pre-calculating the security label and storing the security label in the data record, it is possible to make the security of the data record easily understandable and to make it efficiently accessible. Easy access to this security information can help facilitate auditing of the database system, assist security and information technology professionals in troubleshooting, and with individual data records in the database. Other activities with an understanding of related permits or restrictions can be promoted. For example, by storing the security label of a data record inside the data record itself, the auditor or security expert can refer to a separate security file or table without having to perform complex calculations. By inspecting the record, it is possible to determine which users are allowed or restricted from accessing the data record.

With reference to FIG. 1, the database 100 hosted on the server 101 can include one or more tables 50, 52, 54, 56, each of which is one or more. Includes data records for. A table can be associated with one or more of the other tables in database 100, for example in a hierarchical relationship or another type of relationship. The relationship between the two tables may be, for example, a parent-child relationship in which the child table depends on one or more parent tables. For example, in the example of FIG. 1, the department table 52 is a child of the department table 54, as indicated by the arrow 62. The project table 50 is a child of both the department table 54 and the area table 56, for example, as indicated by arrows 64 and 66. We often refer to the parent table as the upstream table and the child table as the downstream table. Other types of relationships between tables are also possible.

The security module 520 determines whether the user is allowed or restricted from accessing the data records in the database 100. By user 10, we mean any person or entity that attempts to access a data record in database 100. FIG. 1 shows three specific users 10a, 10b and 10c. For example, the user's role (eg, project manager, department manager, officer, or another role), the user's location (eg, northeastern, western, or another), user's security clearance (eg, top secret). , Secret, public, or another clearance), a user's department (eg, HR, technology, marketing, or another department), or associating a user security code 18 with each user 10 based on another characteristic. Can be done. When the user 10 requests access to a particular data record in the database 100, the security module 520 determines the user 10 based on a comparison between the user's user security code 18 and the security label of that particular data record. Determines whether access to a particular data record is allowed or restricted. Since the security label for a particular data record has already been calculated before receiving the user's access request, the security module 520 needs to perform a potentially computationally intensive process of determining the security label of the row. Without this, it is possible to quickly determine whether it is necessary to restrict access to the data record by the user.

Access to database 100 can be restricted row by row. For example, each row in a table has its own, independent of the security label of each other row in the same table, independent of the security label of each row in the other table in database 100. It can have a personalized security label. The row security label may be an aggregated security label with one or more components, each of which is information inside the row, information outside the row, information unique to the table, Or, it is determined independently based on the combination of any two or more of these. The security label for each line can be stored in a field inside the line itself. Each component of the data record security label can represent a restriction on user access to the data record or a permission for user access to the data record. Security module 520 determines whether one or more components of the security label stored within a particular data record restrict access to that particular data record by a user with the particular user security code 18. Can be determined.

In some examples, the data record security label component is determined based on information inside the data record, such as one or more attributes of the data record. A data record attribute is a value, such as a number, string, or another type of value stored in a field of the data record. Attributes can represent information such as roles (discussed below), users, groups of users, business labels, inputs to features, or other information. In one example, the attribute of the data record may be the identifier of the enterprise sector represented by the data record, and the security label component of the data record can be determined based on the identifier of the enterprise sector. In one example, the attribute of the data record may be a clearance value, which is whether the data record is top secret (TS), secret (S), or public (P). It notifies whether it exists, and the component of the security label of the data record can be determined based on the clearance value. In some examples, a single component of a data record security label is based on both the corporate unit identifier represented by the data record and the data record clearance value, and so on. Can be determined based on. In some examples, multiple components of a data record security label can each be determined based on their corresponding attributes.

In some examples, the data record security label component is determined based on information outside the data record, such as the data record security label component in the same table or related data records in different tables. There is. Data records in one table can be associated with rows in the same table or different tables through foreign key relationships. A foreign key is a value stored in a first data record that uniquely identifies the second data record and thus establishes a link between the first and second data records. .. The first and second data records may exist in the same table or in different tables. We often refer to rows that are related through, for example, foreign key relationships or other types of relationships as related rows, and are components of security labels based on the information in the related rows in different tables. The judgment of is called inheritance of the component of the security label. In one example, each data record in the child table represents a project and is associated with a data record in the parent table that represents a corporate unit via a foreign key relationship. Each data record in the project table inherits the security label component from the corresponding component of the associated data record security label in the enterprise department table. Security label inheritance allows high access restrictions to be propagated to relatively low level tables. For example, security label inheritance restricts users from accessing data records that represent technical departments in the corporate department table, and can represent any project data records in the technical department-related project table. User access to data records will also be restricted.

In some examples, the data record security label component is constant for all data records that belong to a given table. For example, all data records in a given table can have a constant value as a component of the security label, and this constant value is an attribute of that table. In one example, within a table that contains data records that represent employee salaries, all data records can have a "confidential" component of the security label.

The row security label component may be based on values inherited from multiple other rows. In some examples, multiple values retrieved from other rows are concatenated to form a component of the row's security label. Multiple values can be concatenated in alphabetical order, in numerical order, in a relationship-based order between rows and each other row, or in a different order. In some examples, the values may be part of an ordered or hierarchical list, and only a single highest priority value among the values is a component of the row security label. It is used as. For example, one related row has a component with a high priority value (eg, "TS") and another related row has a relatively small priority value (eg, "S"). In some cases, the inherited component based on these two rows will inherit the high priority value (“TS”).

The row security label component may be based on multiple elements. In one example, a row security label component may be based on both row attributes and values inherited from the associated row. The security label component may be a concatenation of the attribute and the inherited value, it can also inherit the relatively high priority value of the attribute and the inherited value, or otherwise. You can also combine with.

A row's security label can have multiple components (often referred to as aggregated security labels), in which case each component is determined independently of each other's components. There is. A row security label can be a row attribute, one or more components determined by inheritance, one or more components determined based on information specific to a table, or any two or more of these. It can include one or more components determined based on the combination of.

Some foreign key relationships may be nullable, which means that the foreign key can be missing for a data record without generating an error. When a security label component is determined by inheritance via a nullable foreign key, it can specify a default choice for that component. The default option may be to assign a default value to the security label component, or to leave the security label component blank by ignoring the foreign key relationship, or The value of the component may be determined based on other factors. Some foreign key relationships do not have to be nullable, which means that an error will result if the foreign key value does not exist. No default value is specified when a security label component is determined by inheritance via a non-nullable foreign key.

The rules specific to one or more tables specify how each component of a security label is determined for each record in the table. A table-specific rule is one or more of the attributes, foreign keys, and constants used to determine the security label component for each component of the security label for each data record in the table. Can be specified. Table-specific rules can specify whether to concatenate multiple values, treat them as a hierarchical or ordered list, or treat them in some other way. Table-specific rules can specify default values when foreign key relationships are null. Other rules can also be specified.

In some examples, translation tables, such as look-up tables, can be used to simplify the security label component. The conversion table maps each set of values or combination of values to the corresponding value of another set of values. A translation table can be useful, for example, when a single component of a security label can contain many concatenated values. Such components can be complex and awkward. The translation table can map each possible combination of concatenated values to a relatively simple representation, such as a single value, which is an alternative value within the security label. Can be used.

In some examples, the security label of the data record is determined when the data record is entered into the database 100. In some examples, one or more components of a data record security label make changes to the data record or related data records that can cause changes to the components of the data record security label. It was updated when it was done. For example, when the attributes of a data record are changed, the security label component determined based on the attributes can be updated. When the foreign key is changed, the security label component determined by inheritance can be updated through the foreign key. When a change is made to an upstream data record associated with a downstream data record via a foreign key, the security label component of the downstream data record determined by inheritance through that foreign key. Can be updated. When an upstream data record associated with a downstream data record via a foreign key is deleted, the security label component of the downstream data record determined by inheritance via that foreign key should be updated. Can be done. Other situations can also trigger a data record security label update.

Access to a row can be restricted by using the row security label. Each user of the database system has a user security code, which can include the same component as the security label of the data record in the database. When a user attempts to access a row, each component of the user's user security code is compared to the corresponding component of the row's security label. If any of the components prohibit the user from accessing the row, the user's access to the row is restricted.

In some examples, the row security label component is formed by concatenating one or more values. User access to lines whose security label contains one or more values that are not included in the user's user security code is restricted. For example, a particular row may have a security label with components containing the concatenated values "A, B, C". Access to this line by users whose user security code contains the corresponding component values "A, B" is restricted. Depending on the result of the comparison between each other component of the user security code and the corresponding component of the row security label, the user security code contains the corresponding component values "A, B, C, D". Access to this row by the existing user may be allowed.

In some examples, the values that can form a component of a row's security label are part of an ordered or hierarchical list. Access to all rows with a priority value greater than the user's value by the user with the given value of the corresponding component of the user's user security code is restricted. For example, the security label component value may be selected from the ordered list "TS", "S", "P", where "TS" is the highest priority value and "P". Is the lowest priority value. A particular row may have a security label with a component having the value "S". Access to this line by users whose user security code has the corresponding component value "P" is restricted. This by a user whose user security code has the value "TS" or "S", depending on the result of a comparison between each other component of the user security code and the corresponding component of the row security label. Access to the row may be allowed.

In some examples, one or more of the components of user security code 18 for user 10 may be based on the user's role. By role, we mean a position held by a user, such as a position, a set of responsibilities, a position in a relationship with another person, or another type of position. Illustrative roles can include officer roles, administrative roles, professional staff roles, support roles, or other roles. For example, as in the example of FIG. 1, the department officer 10a, the production worker 10b, and the department manager 10c each play the role of each user in the company for each one or more components of the user security code 18. Has different values based on.

In some examples, the first role can mean one or more other roles, which is one for a user when the first role is assigned to that user. Or several other roles are also meant to be assigned automatically. As a result, the user will be associated with any user security code for one or more of those other roles. For example, the role of a department officer can mean the role of a department manager. As a result, any user with the role of department officer (eg, user 10a) can be automatically assigned the role of department manager, and thus with any user security code for the role of department manager. Can be associated.

With reference to FIG. 2A, the entry in the exemplary database system 950 has a security label with two separate components. The database system 950 stores data representing the delivery source, delivery destination, and means of transportation of each delivery managed by Very Special Deliveries, Inc. The database system 950 includes a plurality of tables associated in a hierarchical relationship by foreign keys. The data record in the delivery table 910 stores data representing the delivery source, delivery destination, means of transportation, and sponsor of each delivery. The source and destination fields in each record in the delivery table 910 are associated with the records in the site table 920 by foreign key relationships, and the records in the site table are associated with the records in the site table, respectively, by foreign key relationships. It is associated with the records in the region table 930. The transport fields in each record in the delivery table 910 are associated with the transport table 940 by a foreign key relationship. The sponsor field in each record in the delivery table 910 is associated with the sponsor table 960 by a foreign key relationship. In this example, only the fields involved in security are shown. The data record may have additional attributes, foreign keys, or both that are not involved in the determination of the security label and are not shown in FIG. 2A.

Permissions within the database system 950 are constrained by an aggregated security label that has two separate and independent components, the classification component (represented in the form of classification: location) and the location component. In this example, the classification component inherits a single value selected from an ordered list with a low priority value (U) and a high priority value (S). The location component can inherit one or more values (NA or EU), and if the location component contains multiple values, the values are concatenated in an alphabetical list.

Within the transport table 940, the security label classification component of each record is determined based on the "classification" attribute of the record. If the "Classification" attribute is "U", the security label classification component inherits the value "U", and if the "Classification" attribute is "S", the security label classification component is the value. It will take over the "S". The record in transport table 940 does not have the value of the location component of the security label. The security label determination of transport table 940 is a security module, such as a code that notifies that the value in the Classification field should be included in the security label classification component of the data record in transport table 940. It can be implemented by the code executed by 520.

Within the region table 930, the location component of the security label for each record is determined based on the "region_code" attribute of the record. If the "Area_Code" attribute is "NA", the security label location component inherits the value "NA", and if the "Area_Code" attribute is "EU", the security label location The component will inherit the value "EU". The record in the region table 930 does not have the value of the security label classification component. The determination of the security label of the area table 930 is such that the value in the "area_code" field needs to be included in the security label classification component of the data record in the area table 930. It can be implemented by code executed by security module 520.

The security label classification component of all records in the sponsor table 960 inherits the value "S". The value "S" is a table-specific constant that applies to all records in the sponsor table 960, regardless of the record's attributes or the record's foreign key relationships. The determination of the security label in the sponsor table 960 is made by the security module 520, for example, a code informing that the value "S" must always be included in the security label classification component of the data record in the sponsor table 960. It can be implemented by the code that is executed.

The record in site table 920 has both a security label classification component and a location component. The security label classification component for each record is determined based on the record's "classification" attribute. The determination of the classification component of each data record in the site table 920 informs, for example, that the value in the "classification" field must be included in the security label classification component of the data record in the site table 920. It can be implemented by code executed by security module 520, such as code.

The location component of the security label for each record in site table 920 is determined by inheritance. Each record in the site table 920 is associated with a record in the region table 930 via a foreign key relationship through a value in the "region" field. Each site record inherits its security label location component from the security label location component of the associated region record. For example, the New York, Chicago, and White Sands site records inherit a location component called "NA" from the North American region record, and the London site record inherits a location component called "EU" from the European region record. ing. The determination of the location component of each data record in site table 920 is implemented by code executed by security module 520, for example, code notifying that foreign keys to region table 930 need to be respected. can do.

The foreign key relationship to the region table 930 is nullable, which means that the region field can be blank without generating an error. In this example, if the foreign key relationship is null for a given data record (for example, if no value exists in the "area" field of that data record), the security label defaults. , It is determined that it is "S" in the classification component and has no value in the location component. Since "S" is the high priority value of the classification component, this default value ensures that the classification component will inherit the value "S" regardless of the value of the classification attribute of the data record. doing. The default behavior of a nullable foreign key is the security module 520, for example, a code that notifies that the security label should be "S:-" if the foreign key relationship to the region table 930 is null. It can be implemented by the code executed by.

The security label classification component and location component of the data record in the delivery table 910 are both determined by inheritance. Each record in the delivery table 910 is associated with one or more other records in the other table via a foreign key relationship, which includes site table 920 ("as a foreign key". Through the "source" and "destination" fields), the transport table 940 (via the "transport" field as a foreign key), and the sponsor table 960 (via the "sponsor" field as a foreign key). ) Is included.

The classification component inherits a single value based on an ordered list where "U" is the low priority value and "S" is the high priority value. The classification component of a given data record is assigned a value that is the highest priority value of the classification component within each of the related data records. Thus, in a given data record, if any of the related data records has a classification component with a value of "S", then the given data record has a value of "S" for the classification component. Assigned.

The location component inherits all of the values of the location component of the related data record in an alphabetically concatenated state. Thus, in a given data record, one of the relevant data records has a location component with a value of "NA" and another of the relevant data records has a location component with a value of "EU". If so, a given data record is assigned a value of "EU, NA" for the location component.

In this example, the foreign keys for transport table 940 and sponsor table 960 are nullable. A default value is provided for each nullable foreign key. If the foreign key to transport table 940 is null for a given data record (for example, if no value exists in the Transport field for that data record), the security label defaults to the classification component. Is "S", and in the location component, it is determined that there is no value. Foreign keys for site table 920 are not nullable. An error occurs if the foreign key to site table 920 is null for a given data record (for example, if no value exists in the "source" or "destination" field of that data record). To do.

The determination of the security label of each data record in the delivery table 910 is made by the code executed by the security module 520 that identifies each foreign key relationship that should be respected and specifies the handling of nulls, as follows: Can be implemented.
Respect FK for delivery source site (not nullable)
Respect FK for delivery site (not nullable)
Respect FK for transportation (use "S:-" if null)
Respect FK for sponsors (ignore if null)

Specifically, the D1 delivery record classification component is the highest priority value among the related record classification components New York (“U”), Chicago (“U”), and Airplane (“U”). Assigned as. The "Sponsor" field is null, so foreign key relationships to the sponsor table 960 are ignored. Therefore, the value "U" is assigned to the classification component of the D1 record. The location component of the D1 delivery record is determined by concatenating the separate values of each of the related record location components New York (“NA”) and Chicago (“NA”). Concatenation is not required because the value of the location component is the same for all related records, and the location component of the D1 delivery record is assigned the value "NA". The aggregated security label for D1 delivery records is "U: NA".

The D2 delivery record classification component is assigned as the highest priority value among the related record classification components New York (“U”), White Sands (“S”), and Airplane (“U”). The "Sponsor" field is null, so foreign key relationships to the sponsor table 960 are ignored. “S” is a higher priority value than “U” and therefore the classification component of the D2 record is assigned the value “S”. The location component of the D2 delivery record is determined by concatenating the separate values of the associated record location components New York (“NA”) and White Sands (“NA”). Therefore, the aggregated label of the D2 delivery record is "S: NA".

The D3 delivery record classification component is assigned as the highest priority value among the related record classification components New York (“U”), London (“U”), and Airplane (“U”). The "Sponsor" field is null, so foreign key relationships to the sponsor table 960 are ignored. Therefore, the classification component of D3 is assigned the value "U". The location component of the D3 delivery record is determined by concatenating the separate values of the associated record location components New York (“NA”) and London (“EU”). By concatenating the two location component values in alphabetical order, the location component value of the D3 delivery record "EU, NA" is formed. Therefore, the aggregated label of the D3 delivery record is "U: EU, NA". Similarly, the aggregated label of the D4 delivery record is "U: EU, NA".

The D5 delivery record classification component is assigned as the highest priority value among the related record classification components New York (“U”), London (“U”), and submarines (“S”). The "Sponsor" field is null, so foreign key relationships to the sponsor table 960 are ignored. “S” is a higher priority value than “U” and therefore the classification component of the D5 record is assigned the value “S”. The location component of the D5 delivery record is determined by concatenating the separate values of the associated record location components New York (“NA”) and London (“EU”). Therefore, the aggregated label of the D3 delivery record is "S: EU, NA".

The D6 delivery record has a null foreign key relationship for the transport field, so the D6 record classification component is "S" by default, regardless of the value of the related record classification component. The location component of the D6 delivery record is determined by concatenating the separate values of each of the related record location components New York (“NA”) and London (“EU”). Therefore, the aggregated label of the D6 delivery record is "S: EU, NA".

The D7 delivery record classification component has the highest priority within the relevant records with the classification components New York (“U”), London (“U”), Airplane (“U”), and Sponsor (“S”). Determined by selecting a classification component value. Therefore, the classification component of D7 is assigned the value "S". The location component of the D7 delivery record is determined by concatenating the separate values of the associated record location components New York (“NA”) and London (“EU”). Therefore, the aggregated label of the D7 delivery record is "S: EU, NA".

Referring to FIG. 2B, each user of the database system 950 shown in FIG. 2A has two separate independent components (represented in the form of classification: location), a classification component and a location component. Have a security code. When a user attempts to access a data record in the database system 950, the value of the user's user security code classification component is compared to the value of the data record security label classification component of the user's user security code. The value of the location component is compared to the value of the location component in the security label of the data record. If the classification or location component prohibits the user from accessing the row, the user's access to the row is restricted.

The user security code classification and location components each inherit the same values available for the classification and location components of the data record security label, respectively. For example, a user security code classification component can be assigned a high priority value of "S" or a low priority value of "U". The location component of the user security code can be assigned "NA", "EU", or "NA, EU".

If the user's user security code classification component has the value "U", then the security label of the user security code and the security label of the data record is of a relatively large classification component, regardless of the value of the component. User access to all data records with a priority value (eg, "S") is restricted. If the user's user security code classification component has the value "S", then the security label classification component is "U" or "S", depending on the value of the user security code and the security label location component of the data record. User access to the data record with "" may be allowed. If the data record security label classification component is blank, there are no restrictions imposed by the classification component and user access to the data record is controlled by the location component.

If the location component of the user's user security code has the value "NA", then the user's access to all data records that have a location component whose security label has any value other than "NA" is restricted. .. Thus, for example, access by the user to a data record having a location component whose security label has the value "EU" or "EU, NA" will be restricted. If the user's user security code location component has the value "EU, NA", then "NA" for that security label location component, depending on the value of the user security code and data record security label classification component. , "EU", or "EU, NA" may be allowed for user access to the data record. If the location component of the security label is blank, there are no restrictions imposed by the location component and the user's access to the data record is controlled by the classification component.

If the classification or location component restricts the user's access to the data record, the user's access to the data record is restricted. For example, by user 1 with the user security code "U: NA", all data records whose security label has "S" for the classification component and any value other than "NA" whose security label is in the location component. Access to all data records, including, is restricted. Access to all data records whose security label has an "S" for the classification component by user 2 with the user security code "U: EU, NA" is restricted, but user 2 is the value of the location component. Has no restrictions on. User 3 with the user security code "S: NA" has no restrictions on the value of the classification component, but all that security label contains any value other than "NA" within the location component. Access to the data record by user 3 is restricted. The user 4 having the user security code "S: EU, NA" has no restriction on access to the data record.

In this example, the security label for each entry has one ordered component (classification component) and one unordered component (location component). In some examples, security labels can have multiple ordered or hierarchical components, can have multiple unordered components, or both. You can also have.

In this example, security label component inheritance is propagated through multiple generations of table hierarchies. If the extension has child tables, such as the DeliveryItem table, where the delivery table 910 has its entries related by a foreign key relationship to the entries in the delivery table 910, the label inheritance is similar to that described above. By the above method, it will continue in the DeliveryItem table.

By storing the security label of a row inside the row itself, it is possible to quickly and easily determine the access restriction of that row. For example, when a user attempts to access a row, the row does not require real-time identification of the relevant row or calculation of a security label (eg, while the user is attempting to access the row). A direct comparison between the security label of the user and the user's user security code can determine the user's ability to access a particular line. Therefore, this method can provide relatively quick and reliable access to secure rows in the database. Also, storing the security label of a row inside the row itself will facilitate security audits or maintenance of security settings, which requires references to other tables or complex logical decisions. This is because the security label is visible and easily understandable without doing anything.

With reference to FIG. 3, the system 500 can determine, for example, the security label 502 of the data record 504 input to the database 90 by the computer 506. The data record 504 may be a new data record added to the database 90, or may be an update to a data record already stored in the database 90.

The detection module 510 detects changes to attributes and foreign key relationships that may affect the components of security label 502 for one or more data records in database 90. The detection module 510 detects the incoming data record 504 and determines whether to send the data record 504 to the security module 520 in order to calculate the security label 502 of the data record 504. For example, if the data record 504 is a new data record, the detection module 510 automatically sends the data record 504 to the security module 520. If the data record 504 is an update to a pre-stored data record, the detection module 510 asks if the update to the data record can affect one or more components of the security label of the data record 504. To judge. Updates that can affect one or more components of a security label include, for example, updates to the attributes of the data record used in determining the component of the security label, and foreign key relationships where the component of the security label is determined. Includes an update or another update. Updates that do not affect any component of the security label include, for example, updates to attributes or foreign key relationships that are not used in the security label determination. If the detection module 510 determines that the update may affect the security label of the data record 504, the detection module 510 sends the updated data record 504 to the security module 520. If the detection module 510 determines that the update does not affect the security label of the data record, the determination module 510 sets the data record 504 to the cascade module 550 (described below), for example by bypassing the security module 520. ) Can be sent directly.

In some examples, the detection module 510 secures the incoming data record 504 according to one or more rules 532 stored in the rules database 530 or the rules file, or otherwise stored in the security module 520. It is possible to determine whether or not to send to. Illustrative rule 532 can notify that new data record 504 needs to be sent through security module 520. Illustrative rules can specify the attributes of a data record in a particular table in database 90 (eg, the table in which the data record 504 is stored) used in determining the components of the data record security label. Yes, it is possible to notify that an updated data record 504 with a change to one or more of the defined attributes needs to be sent through the security module 520. An exemplary rule is that of a data record in a particular table in database 90 (eg, a table in which data record 504 is stored) that contains foreign key values that relate the updated data record 504 to other data records. It is possible to specify one or more fields, and an updated data record 504 with changes to one or more of the specified foreign key fields needs to be sent through security module 520. You can notify that. For example, rule 532 states that a change in foreign key value that could result in data record 504 being associated with a different upstream data record triggers a send through security module 520, while data record 504 is a different downstream. It is possible to notify that a change in foreign key value that may result in being associated with a data record of the data record 504 results in being sent directly to the cascade module 550.

The security module 520 determines the security label 502 of the incoming or updated data record 504. The security module 520 can determine the security label 502 based on the rule 532 stored in the rule database 530. Each table in database 90 can have a separate set of one or more rules 532. The rules for a given table specify how each component of a security label is determined for each record in that table. For each component of the security label, the rule can identify one or more of the attributes, foreign keys, and constants that need to be used in determining the component of the security label. Rules can specify whether multiple values used in determining a given component need to be concatenated or processed as a hierarchical list or an ordered list. The rule can specify a default value for a component of a security label or a default value when a nullable foreign key relationship is null, such as a notification to ignore a null foreign key. Once the security label 502 has been determined for the incoming or updated data record 504 in accordance with Rule 532, the security label 502 is added to the data record 504 and the data record 504 containing the security label 502 is stored in the database 90. Will be done.

The data record 504 is also sent to the cascade module 550. Cascade module 550 determines other records, such as downstream records, that may need to have a recalculated security label as a result of updates to data record 504. For example, Cascade Module 550 identifies downstream records 514 associated with data record 504, eg, through a foreign key relationship, and downstream of them, for example, for recalculation of individual security labels, as described above. Record 514 is sent to the security module 520. In some examples, the cascade module 550 identifies the foreign key that associates data record 504 with other downstream data records, according to one or more rules 532, downstream associated record 514. Can be identified.

Once the downstream data record 514 has been processed by the security module 520, its security label may be updated in database 90 and the downstream data record 514 may be recalculated with the security label of the data record downstream of that data record 514. As such, it is sent to the cascade module 550. This cascade of security label recalculations can continue, for example, until no further downstream data records are available.

System 500 can perform a security label recalculation when a data record is deleted from database 90. The detection module 510 detects that the data record needs to be deleted from the database 90 and sends the data record to the cascade module 550. Cascade module 550 determines other records, such as downstream records, that may need to have a recalculated security label as a result of deleting the data record. For example, Cascade Module 550 identifies downstream records 514 associated with data records, eg, through foreign key relationships, and downstream of them, for example, for recalculation of individual security labels, as described above. Record 514 is sent to security module 520.

In some examples, the security module 520 can maintain a log 518 of security label calculations. For example, log 518 shows the identifier of the data record whose security label was calculated or recalculated, the date of change, the time of change, the previous value of the security label, the reason for the change (eg, the upstream relationship that triggered the recalculation). It can include identification information of the record, or notification that the data record is new or updated), or other information, or a combination of any two or more of these.

With reference to FIG. 4, the system 500 can respond to an access request from the user 600 to the data record 602 stored in the database 90. The user has a user security code 604. When the user 600 requests access to the data record 602, the security module 520 acquires the security label 606 of the data record 602 from the database 90. Security module 520 can then compare each of the components of security label 606 of data record 602 with the corresponding component of user security code 604 in accordance with Rule 532. If each of the components of the user's user security code 604 satisfies the corresponding component of security label 606, the user 600 can access the data record 602. If one or more of the components of the user's user security code 604 do not meet the corresponding component of security label 606, the user's access to the record is restricted. A screen 610 that allows the user 600 to access one or more data records 602 that the user is allowed to access can be presented to the user 600.

Referring to FIG. 5, in a general method of determining the security label of an incoming data record, the data record is received for storage in a table of the database (800). One or more rules have been acquired that indicate how the security label is determined for the data record (802). Each component of the security label is determined according to the rules (804). Determining the security label component can include determining the security label component based on the attributes of the data record (806). Determining a security label component can include determining a security label component based on inheritance of values from another data record associated via a foreign key relationship (808). The determination of the security label component can include the step (810) of determining the security label component based on a certain value associated with the table. The security label is stored in a field in the data record (812).

Referring to FIG. 6, in the general method of updating the security label of the updated data record, the update for the data record stored in the database is received (600). One or more rules have been obtained indicating how the security label is determined for the data record (602). If the update affects the attributes used in determining the component of the data record's security label, or the update affects the foreign key relationship between the updated data record and the upstream data record. If it affects it, or in both cases (604), the security label component of the affected data record is recalculated, for example, as described above (606). .. If the update does not affect any element of the data record used in the security label determination (604), the data record security label is not recalculated (608). Downstream related data records have been identified (610). If the security label of the data record is recalculated, or if the update affects the foreign key relationship between the updated data record and the downstream data record, the security calculation process will It is executed for each of the related records downstream (612). The process terminates when no further downstream records exist (614).

Referring to FIG. 7, the data record is deleted in a general method of deleting the data record from the database (900). Downstream related data records have been identified (902). The security label component is recalculated for each of the downstream related records, for example, as described above (904). The process is terminated when there are no further downstream records (906).

In some cases, the row security label controls which users are allowed or restricted to read the row. In some cases, the row security label controls who is allowed or restricted to write to the row. In some cases, each row can have two security labels: a label that controls the user who can read the row and a label that controls the user who can write to the row.

In some examples, such as the one given earlier, the security label component of a row in a table is determined based on the information in each of one or more related rows in another table. In some examples, the security label component of a row in a table can be determined based on the information in each of one or more related rows in the same table. Determining a row security label component based on information in related rows in the same table is a cyclical relationship between rows in a table, such as when the relationships between rows are hierarchical. Can be done when not.

In some examples, the security label component for a particular row in a table is based on the information in the row that is associated with the particular row through multiple chains of references, but one in the chain of references. The determination can be made without being based on the information in one or the middle line. For example, each row in table A can be associated with a row in table B, and each row in table B can be associated with a row in table C. The security label component of each row in table A can be determined based on the information in the relevant row in table C, but not based on the information in the relevant row in table B. ..

In some examples, the security label for each row in a table can, by default, be determined based on information in any related row in the same table or another table. In some cases, the user overrides the default value so that the security label on the row does not conform to any foreign key relationship, or to one or more specific foreign key relationships. be able to. In some examples, the security label for each row in the table cannot conform to any foreign key relationship by default. In some cases, the user may want the security label for each row in the table to comply with one or more specific foreign key relationships, or all foreign key relationships. You can override the default value.

In some examples, the default method for foreign key relationships may depend on the characteristics of the foreign key. For example, if a particular foreign key is nullable, the default value may be that it does not conform to that foreign key relationship in the security label determination, but if the particular foreign key is not nullable. The default value may be that it conforms to the foreign key relationship in determining the security label. If a particular external key is not nullable, but nevertheless, it is the most restrictive security label, the most frequently used security label, the user-specified security label, or An alternative security label, such as another security label, can be specified.

In some examples, row-level security is applied to all tables in the database, for example row-level security based on information outside the table. In some examples, row-level security is applied only to some of the tables in the database.

In some examples, column-level security can be provided in a manner similar to that described above in relation to row-level security. For example, additional rows can be provided in the table to include column-level security labels. The value of a field in a row of column-level security may be based on information outside the table, information inside the table, or both.

In some examples, row-level security can be propagated through various object classes, such as hierarchical object classes in the database. For example, row-level security can be applied at the database level, at the schema level, at the table level, or at another level.

Referring to FIG. 8, in a general method of determining whether to restrict access to a record by a user, an access request to a data record is received from or on behalf of the user (850). .. A user security code for the user has been obtained (852), which can include one or more components. The security label of the requested data record has been obtained (854). One or more rules controlling user access restrictions have been acquired (856), and each component of the user's user security code is compared to the corresponding component of the security label of the data record (858). If any of the user's user security codes prohibits the user from accessing the data record (860), access to the data record is denied (862). If the component of the user's user security code does not prohibit the user from accessing the data record (860), then the user can access the data record (864).

With reference to FIG. 9, in some examples, the technique described above can be implemented within a data processing system 150 that includes a data source 102 and an execution environment 104. The data source 102 may include one or more sources of data, such as a connection to a storage device or an online data stream, each of which has a variety of formats (eg, database tables, spreadsheet files, etc.). Data may be stored or provided in either a flat text file or the native format used by the mainframe. The execution environment 104 includes a preprocessing module 106 and an execution module 112. The execution environment 104 may be hosted on one or more general purpose computers under the control of an appropriate operating system, for example, one version of the UNIX operating system. For example, the execution environment 104 is a local type (for example, a multiprocessor system such as a symmetric multi-processing (SMP) computer), a locally distributed type (for example, a cluster or massively parallel processing (MPP)). Multiple processors combined as a system), remote, remote distributed (eg, Local Area Network (LAN) and / or Wide-Area Network (WAN)). A multi-node parallel computing environment including the configuration of a computer system using a plurality of central processing units (CPUs) or processor cores, which is an arbitrary combination thereof.

The pre-processing module 106 reads data from the data source 102, performs any appropriate processing of the data, and stores the processed data. The storage device providing the data source 102 may be locally connected to the execution environment 104, for example, the data may be a storage medium (eg,) connected to the computer hosting the execution environment 104. , Hard drive 108) may be stored. The storage device may also be remotely connected to the execution environment 104, eg, with a computer hosting the execution environment 104 on a remote connection (eg, one provided by a cloud computing infrastructure). It may be hosted on a remote system (eg, mainframe 110) in the communication state of.

Execution module 112 uses the processed data generated by preprocessing module 106 to execute the specified process. The processing module 106 may output the data 114, which may be stored again in the data source 102 or in the data storage system 116 accessible from the execution environment 104, or It may be used in other ways. The data storage system 116 is also accessible from the development environment 118 where the developer 120 can develop a data processing application. The development environment 118, in some implementations, is a vertex (data processing component or data processing component or) connected by a directed link (representing the flow of work elements, ie, data) between the vertices. It is a system for developing an application as a calculation graph or a data flow graph including (representing a data set). For example, such an environment is described in more detail in US Patent Application Publication No. 2007/0011668 entitled "Managing Parameters for Graph-Based Applications". A system for performing calculations based on such graphs is described in US Pat. No. 5,966,072, entitled "EXECUTING COMPUTATIONS EXPRESSED AS GRAPHS". Data flow graphs generated according to this system provide a way to exchange information with and from the individual processes represented by the graph components, move information between processes, and define the order of operation of the processes. There is. The system includes an algorithm that selects an interprocess communication method from any available method (eg, a graph link communication path is a TCP / IP or UNIX domain socket to convey data between processes. It is also possible to use, or shared memory can be used).

The data flow graph developed using the development environment 118 can be stored, for example, in the data storage 116 and can be accessed by the execution environment 104. The execution environment 104 may execute the data flow graph in order to execute the process associated with the component of the data flow graph and process the data received from the data source 102.

The method of generating the connection described above can be implemented using an arithmetic system running appropriate software. For example, the data processing system 100 can be implemented using an arithmetic system having one or more data processors that execute instructions. For example, the software receives input using at least one processor, at least one data storage system (including volatile and / or non-volatile memory and / or storage elements), and at least one input device or port. One, each containing at least one user interface (to provide output using at least one output device or port) (which can have various architectures such as distributed, client / server, or grid). Alternatively, it may include procedures within one or more computer programs running on multiple programmed or programmable computing systems. The software may include, for example, one or more modules of a relatively large program that provides services related to the design, configuration, and execution of a data flow graph. Program modules (eg, data flow graph elements) can be implemented as data structures or other organized data that conform to the data model stored within the data repository.

The software may or may be provided on a tangible, non-transitory medium such as a CD-ROM or other computer-readable medium (eg, readable by a general purpose or special purpose computing system or device). In such cases, it may be supplied to a tangible, non-transient medium of the computing system (eg, in the encoded state in the propagated signal) on the communication medium of the network. Some or all of the processing can be done on a special purpose computer, or in a coprocessor, or field-programmable gate array (FPGA), or a dedicated application specific integrated circuit (ASIC:). It may be executed using special purpose hardware such as Application-Specific Integrated Circuit). The processing may be implemented by a distributed method in which different parts of the operation specified by the software are executed by different arithmetic elements. Each such program is preferably general purpose or special for the storage device medium to configure and operate the computer when read by the computer to perform the processes described herein. Purpose Stored or downloaded onto a computer-readable storage medium (eg, semiconductor memory or medium, or magnetic or optical medium) of a storage device accessible by a programmable computer. Also, the system of the present invention may be considered to be implemented as a tangible, non-temporary medium constructed by a computer program, in which case the medium thus constructed is by the computer. To operate in a specific and predefined manner to perform one or more of the processing steps described in the specification.

So far, some embodiments have been described. However, it should be understood that the above description is not a limitation of the scope of the invention defined by the appended claims, but is intended to illustrate this. Therefore, the scope of the appended claims also includes other embodiments. For example, various modifications may be made without departing from the scope of the invention. In addition to this, some of the steps described above may be order-independent and therefore can be performed in a different order than described.

Claims (71)

It is a step of determining the component of the security label of the first record in the first table of the database having a plurality of tables by the computer.
A step of identifying a second record related to the first record according to a foreign key relationship,
The step of identifying the component of the security label in the second record, and
A step of assigning a value of the component of the security label of the first record based on the identified component of the security label of the second record.
With steps and
A step of storing the determined security label in the first record by the computer,
How to include. A step of identifying a plurality of second records related to the first record according to individual foreign key relationships, and
A step of identifying the component of the security label for each of the second records,
A step of assigning the value of the component of the security label of the first record based on the value of each component of the identified component of the security label of the second record.
The method according to claim 1. 2. The step of assigning the value of the component of the security label of the first record includes the step of concatenating a plurality of distinct values of the identified component of the security label of the second record. the method of. The step of assigning the value of the component of the security label is
A step of identifying the highest priority value from the values of the identified component of the security label of the second record, and
A step of assigning the highest priority value as the value of the component of the security label of the first record, and
2. The method according to claim 2. Based on an attribute of the third record includes automatically determining a component of the security label for each third record in the third table of said database, said third record attributes, the third in the record The method according to claim 1, which is a value stored in. The method of claim 1 comprising automatically determining a component of the security label for each third record before Symbol in the third table based on the value associated with the third table of the database. The method according to claim 1, wherein the second record exists in a table other than the first table. The method according to claim 1 , wherein the component is the first component of the security label of the first record, and the method comprises a step of determining a second component of the security label. The method of claim 1, comprising the step of updating the component of the security label of the particular first record in response to a trigger event. The method of claim 9, wherein the trigger event includes a change in the foreign key relationship. The method of claim 9, wherein the trigger event comprises a change in the component of the security label of the second record related to the particular first record. 9. The method of claim 9, comprising the step of detecting the trigger event. 9. The method of claim 9, comprising the step of receiving a notification of the trigger event. The method of claim 1, wherein the user comprises receiving an access request for a particular first record from the user, wherein the user is associated with a user security code. A step of restricting access by the user to the particular first record based on a comparison between the component of the user security code associated with the user and the component of the security label of the particular first record. The method according to claim 14. 15. The method of claim 15, comprising the step of determining the security label of the first record before receiving the access request. The method of claim 1, comprising the step of automatically determining the component of the security label of a particular first record when the first record is received for storage in the database. A non-transitory computer-readable medium that stores instructions
The instruction is issued by the arithmetic system.
It is to automatically determine the component of the security label of the first record in the first table of the database having multiple tables.
A step of identifying a second record related to the first record according to a foreign key relationship,
In the step of identifying the component of the security label in the second record,
A step of assigning a value of the component of the security label of the first record based on the identified component of the security label of the second record.
Judgment including
The determined security label is stored in the first record.
The medium to do. It's an arithmetic system
Equipped with a processor coupled to memory
The processor and memory
It is to automatically determine the component of the security label of the first record in the first table of the database having multiple tables.
A step of identifying a second record related to the first record according to a foreign key relationship,
In the step of identifying the component of the security label in the second record,
A step of assigning a value of the component of the security label of the first record based on the identified component of the security label of the second record.
Judgment including
The determined security label is stored in the first record.
The system is configured so that. It's an arithmetic system
A means for automatically determining the security label component of the first record in the first table of a database having multiple tables.
A step of identifying a second record associated with the first record according to a foreign key relationship,
The step of identifying the component of the security label in the second record, and
A step of assigning a value of the component of the security label of the first record based on the identified component of the security label of the second record.
Including means and
A means for storing the determined security label in the first record, and
A system equipped with. A step of determining that the first record stored in the first table of a database having a plurality of tables has been updated by the computer.
The step of automatically updating the first security label of the first record by the computer,
A step of storing the updated security label in the first record by the computer.
A step of updating the second security label of the second record stored in the second table of the database by the computer.
The method in which the second record is associated with the first record according to a foreign key relationship. 21. The method of claim 21, comprising determining whether the update to the first record affects the first security label of the first record. A step of determining one or more of the components of the first security label that are affected by the update to the first record.
A step of automatically updating one or more of the affected components of the first security label.
21. The method of claim 21. 21. The method of claim 21, wherein the second table is a child of the first table. 21. The method of claim 21, comprising determining whether the update to the first record affects the foreign key relationship. A step of determining one or more foreign key relationships among a plurality of foreign key relationships affected by the update to the first record.
A step of automatically updating the second security label of each second record associated with the first record according to the affected foreign key relationship.
21. The method of claim 21. A non-transitory computer-readable medium that stores instructions
The instruction is sent to the arithmetic system.
It is determined that the first record stored in the first table of the database having a plurality of tables has been updated.
The first security label of the first record is automatically updated,
The updated security label is stored in the first record and stored.
The second security label of the second record stored in the second table of the database is automatically updated, and the second record is associated with the first record according to the foreign key relationship. Medium. It's an arithmetic system
Equipped with a processor coupled to memory
The processor and memory
It is determined that the first record stored in the first table of the database having a plurality of tables has been updated.
The first security label of the first record is automatically updated,
The updated security label is stored in the first record,
The second security label of the second record stored in the second table of the database is automatically updated, and the second record is associated with the first record according to the foreign key relationship.
The system is configured so that. It's an arithmetic system
A means for determining that the first record stored in the first table of a database having a plurality of tables has been updated, and
A means for automatically updating the first security label of the first record,
A means for storing the updated security label in the first record, and
It is a means for automatically updating the second security label of the second record stored in the second table of the database, and the second record is associated with the first record according to a foreign key relationship. There are means and
A system equipped with. In the arithmetic system
A step of identifying a plurality of second records related to the first record according to individual foreign key relationships, and
A step of identifying the component of the security label for each of the second records,
A step of assigning the value of the component of the security label of the first record based on the value of each component of the identified component of the security label of the second record.
The computer-readable medium according to claim 18, which stores an instruction to execute. 30. The step of assigning the value of the component of the security label of the first record comprises the step of concatenating a plurality of distinct values of the identified component of the security label of the second record. Computer-readable medium. The step of assigning the value of the component of the security label is
A step of identifying the highest priority value from the values of the identified component of the security label of the second record, and
A step of assigning the highest priority value as the value of the component of the security label of the first record, and
30. The computer-readable medium according to claim 30. In the arithmetic system
To execute automatically determining a component of the security label for each third record in the third table of the database based on the attribute of the third record, store instructions,
The third record attributes, computer-readable medium of claim 18 wherein the third a value stored in the record. In the arithmetic system
To execute automatically determining a component of the security label for each third record before Symbol in the third table based on the value associated with the third table of the database, to claim 18 storing instructions The computer-readable medium described. The computer-readable medium according to claim 18, wherein the second record exists in a table other than the first table. It said component is a first component of the security label of the first record,
In the arithmetic system
The computer-readable medium of claim 18, which stores an instruction to perform a step of determining a second component of the security label. In the arithmetic system
The computer-readable medium of claim 18, which stores an instruction to perform a step of updating the component of the security label in a particular first record in response to a trigger event. The computer-readable medium according to claim 37, wherein the trigger event includes a change in the foreign key relationship. The computer-readable medium of claim 37, wherein the trigger event comprises a change in the component of the security label of the second record related to the particular first record. In the arithmetic system
The computer-readable medium according to claim 37, which stores an instruction to execute a step of detecting the trigger event. In the arithmetic system
The computer-readable medium according to claim 37, which stores an instruction to execute a step of receiving a notification of the trigger event. In the arithmetic system
The computer-readable medium of claim 18, which stores an instruction that causes a user to perform a step of receiving an access request for a particular first record, the user being associated with a user security code. In the arithmetic system
Perform a step of restricting access by the user to the particular first record based on a comparison between the component of the user security code associated with the user and the component of the security label of the particular first record. The computer-readable medium according to claim 42, which stores an instruction. In the arithmetic system
The computer-readable medium according to claim 43, which stores an instruction to execute a step of determining the security label of the first record before receiving the access request. In the arithmetic system
18. Claim 18, which stores an instruction that causes a step of automatically determining the component of the security label of a particular first record when the first record is received for storage in the database. The computer-readable medium described. The processor and memory
A step of identifying a plurality of second records related to the first record according to individual foreign key relationships, and
A step of identifying the component of the security label for each of the second records,
A step of assigning the value of the component of the security label of the first record based on the value of each component of the identified component of the security label of the second record.
19. The arithmetic system according to claim 19, which is configured to execute. 46. The step of assigning the value of the component of the security label of the first record includes the step of concatenating a plurality of distinct values of the identified component of the security label of the second record. Computational system. The step of assigning the value of the component of the security label is
A step of identifying the highest priority value from the values of the identified component of the security label of the second record, and
A step of assigning the highest priority value as the value of the component of the security label of the first record, and
46. The arithmetic system according to claim 46. The processor and memory
It is configured to perform a step of automatically determining the component of the security label for each third record in the third table of the database based on the attributes of the third record, and the attributes of the third record. Is the arithmetic system according to claim 19, which is a value stored in the third record. The processor and memory
Third each of the third claim for each record is configured to execute automatically determining a component of the security label in the previous Symbol third table based on the value associated with the table 19 of the database The arithmetic system described in. The arithmetic system according to claim 19, wherein the second record exists in a table other than the first table. It said component is a first component of the security label of the first record,
The processor and memory
19. The arithmetic system according to claim 19, which is configured to perform a step of determining a second component of the security label. The processor and memory
19. The arithmetic system of claim 19, which is configured to perform a step of updating the component of the security label of the security label in a particular first record in response to a trigger event. The arithmetic system according to claim 53, wherein the trigger event includes a change in the foreign key relationship. The arithmetic system according to claim 53, wherein the trigger event includes a change in the component of the security label of the second record related to the particular first record. The processor and memory
The arithmetic system according to claim 53, which is configured to perform a step of detecting the trigger event. The processor and memory
The arithmetic system according to claim 53, which is configured to perform a step of receiving a notification of the trigger event. The processor and memory
The arithmetic system according to claim 19, which is configured to perform a step of receiving an access request for a particular first record from a user, wherein the user is associated with a user security code. The processor and memory
A step of restricting access by the user to the particular first record is performed based on a comparison between the component of the user security code associated with the user and the component of the security label of the particular first record. 58. The arithmetic system according to claim 58. The processor and memory
The arithmetic system according to claim 59, which is configured to perform a step of determining the security label of the first record before receiving the access request. The processor and memory
19. Claim 19 configured to perform a step of automatically determining the component of the security label of a particular first record when the first record is received for storage in the database. The arithmetic system described in. In the arithmetic system
27. The computer-readable medium of claim 27, which stores an instruction to execute a step of determining whether the update to the first record affects the first security label of the first record. In the arithmetic system
A step of determining one or more of the plurality of components of the first security label that are affected by the update to the first record.
A step of automatically updating one or more of the affected components of the first security label.
27. The computer-readable medium according to claim 27, which stores an instruction for executing. The computer-readable medium according to claim 27, wherein the second table is a child of the first table. In the arithmetic system
27. The computer-readable medium of claim 27, which stores an instruction to execute a step of determining whether the update to the first record affects the foreign key relationship. In the arithmetic system
A step of determining one or more foreign key relationships among a plurality of foreign key relationships affected by the update to the first record.
A step of automatically updating the second security label of each second record associated with the first record according to the affected foreign key relationship.
27. The computer-readable medium according to claim 27, which stores an instruction for executing. The processor and memory
28. The arithmetic system of claim 28, which is configured to perform a step of determining whether the update to the first record affects the first security label of the first record. The processor and memory
A step of determining one or more of the plurality of components of the first security label that are affected by the update to the first record.
A step of automatically updating one or more of the affected components of the first security label.
28. The arithmetic system according to claim 28, which is configured to execute. The arithmetic system according to claim 28, wherein the second table is a child of the first table. The processor and memory
28. The arithmetic system of claim 28, which is configured to perform a step of determining whether the update to the first record affects the foreign key relationship. The processor and memory
A step of determining one or more foreign key relationships among a plurality of foreign key relationships affected by the update to the first record.
A step of automatically updating the second security label of each second record associated with the first record according to the affected foreign key relationship.
28. The arithmetic system according to claim 28, which is configured to execute.

Images