Implementing multi-security-level control for predicate access for fine-grained privacy protection columns

Abstract

This disclosure describes techniques for implementing multi-security-level control of predicate access for a fine-grained privacy protection column. And configuring a predicate directory table. The predicate table is configured to control predicate surviving users to access the fine-grained privacy protection column. A first instruction is received from an owner of one of the fine-grained privacy protection columns that grants the user with predicate access to the one of the fine-grained privacy protection columns. And determining whether there is a match based on comparing the identification information and the operator information in the predicate directory table with the information indicated by the first instruction. In response to determining that there is no match, a new line is created in the predicate directory table based on the first instruction. The new row is configured to control predicate access rights of the user to the one of the fine-grained privacy protection columns.

Description

Background Technology

[0001] Some data may be sensitive or confidential. Access to such data may be restricted to a specific set of stakeholders. For example, sensitive or confidential data can be encrypted, making it accessible only to authorized parties. As the amount of sensitive or confidential data continues to increase, the desire for new methods for managing data access is growing. Attached Figure Description

[0002] The following detailed embodiments can be better understood when read in conjunction with the accompanying drawings. For illustrative purposes, exemplary embodiments of various aspects of this disclosure are shown in the drawings; however, the invention is not limited to the specific methods and tools disclosed.

[0003] Figure 1 An example system for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns, according to this disclosure, is shown.

[0004] Figure 2 An example system for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns, according to this disclosure, is shown.

[0005] Figure 3 An example predicate catalog table according to this disclosure is shown.

[0006] Figure 4 An example predicate catalog table according to this disclosure is shown.

[0007] Figure 5 An example predicate catalog table according to this disclosure is shown.

[0008] Figure 6 An example predicate catalog table according to this disclosure is shown.

[0009] Figure 7 An example predicate catalog table according to this disclosure is shown.

[0010] Figure 8 An example predicate catalog table according to this disclosure is shown.

[0011] Figure 9 An example predicate catalog table according to this disclosure is shown.

[0012] Figure 10 An example predicate catalog table according to this disclosure is shown.

[0013] Figure 11 An example process for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns, according to this disclosure, is shown.

[0014] Figure 12An example process for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns, according to this disclosure, is shown.

[0015] Figure 13 An example process for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns, according to this disclosure, is shown.

[0016] Figure 14 An example process for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns, according to this disclosure, is shown.

[0017] Figure 15 An example process for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns, according to this disclosure, is shown.

[0018] Figure 16 An example process for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns, according to this disclosure, is shown.

[0019] Figure 17 An example computing device is shown that can be used to perform any of the techniques disclosed herein. Detailed Implementation

[0020] Privacy-preserving and verifiable in-enclave (e.g., fully hardware-encrypted) relational databases can be implemented by residing the entire database management system (DBMS) within a hardware-based security engine that isolates and protects the data in use from attacks within a virtual machine (VM). In this fully hardware-encrypted database architecture, the security of all memory, (multiple) central processing units, and input / output (I / O) is protected against data leakage. Therefore, adversaries cannot view any data structures and data stores used internally by the DBMS, such as system logs and physical logs, that do not have explicit retrieval interfaces.

[0021] When creating or modifying tables in a hardware-encrypted database schema, privacy-protected columns can be defined using the additional keyword "SECRET". The owner of the secret column can see the column in plaintext. Other users cannot observe the plaintext in any way (such as data retrieval, predicate processing, log probing, or statistical viewing). The owner can perform Data Control Language (DCL) operations to grant column visibility to another user (e.g., using the "GRANT VIEWER DCL" command) and remove or revoke a user's visibility control (e.g., using the "DENY" or "REVOKE" commands). These DCL operations can only be performed by the secret column owner to prevent accidental operations by high-privilege roles (such as database administrators (DBAs)).

[0022] The owner of a privacy-protected column can control its visibility by granting, denying, or revoking viewing access to another user, for example, using the GRANT, DENY, or REVOKE commands respectively. If a user who has not yet been granted viewing access to a privacy-protected column attempts to execute a DML command containing a predicate that includes the privacy-protected column, an error is returned. The owner of a privacy-protected column may want to grant users who are not viewers of the privacy-protected column limited access to confidential information within it (e.g., predicate access). To grant a user predicate access to confidential information within the privacy-protected column, the owner can grant that user predicate access to the privacy-protected column, for example, using the GRANT command. The owner can specify one or more predicate operators that the user can run, the number of queries that the user can run containing predicate operators(s), and the time interval at which the number of queries that the user can run containing predicate operators(s) can be reset. The owner can also revoke a user's predicate access to the privacy-protected column, for example, using the REVOKE command.

[0023] This paper describes an improved technique for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns. The technique described in this paper enables the owner of a fine-grained privacy-preserving column to control predicate access to that column. Figure 1 An example system 100 for managing ownership of fine-grained privacy-preserving columns according to this disclosure is shown. System 100 includes a DBMS 108, multiple end-user devices 104a-n, and at least one database 110.

[0024] At least one database 110 may store data, such as in the form of one or more tables. Each of the tables (or tables) may include one or more fine-grained privacy-preserving columns. Each fine-grained privacy-preserving column may include confidential information. Each fine-grained privacy-preserving column may be qualified with the additional keyword "secret". Only the owner of a particular fine-grained privacy-preserving column may be permitted to perform DCL operations associated with that fine-grained privacy-preserving column. The owner of a particular fine-grained privacy-preserving column may be associated with one or more end-user devices among a plurality of end-user devices 104a-n. Only one or more end-user devices associated with that owner may be used to perform DCL operations associated with that fine-grained privacy-preserving column.

[0025] DBMS108 can create a predicate directory table. This table can be configured to control access to fine-grained privacy-preserving columns by predicate survivor users. Each predicate survivor user can be granted access to query at least one fine-grained privacy-preserving column using at least one predicate operator. This predicate operator can include one or more of the following operators: = (e.g., equal to), > (e.g., greater than), < (e.g., less than), ≤ (e.g., less than or equal to), ≥ (e.g., greater than or equal to), "notin", "between", and / or any other operator. In some embodiments, a predicate survivor user can be granted access to query at least one fine-grained privacy-preserving column using any predicate operator (e.g., when the operation information in a row of the predicate directory table is a "null" value).

[0026] Each row of the predicate directory table may include identification information. This identification information may include the identification information of a specific fine-grained privacy-protected column, the identification information of the owner of the specific fine-grained privacy-protected column, and the identification information of a specific predicate surviving user. Each row of the predicate directory table may include operator information. This operator information may indicate one or more predicate operators that a predicate surviving user can use to query a fine-grained privacy-protected column. Each row of the predicate directory table may include control information for controlling a specific predicate surviving user's access to a specific fine-grained privacy-protected column. This control information may include information indicating the quantity limit allowed for a specific predicate surviving user to query a specific fine-grained privacy-protected column using one or more predicate operators (e.g., the number of times a predicate surviving user is allowed to query a specific fine-grained privacy-protected column using one or more predicate operators). This control information may also include information indicating the reset interval for the quantity limit (e.g., the time interval at which the number of queries containing (multiple) predicate operators that a user can run is reset).

[0027] In response to receiving a first instruction from the owner of a fine-grained privacy protection column, a user may be granted predicate access rights to that fine-grained privacy protection column. The first instruction may be associated with the owner's identification information. The owner may be associated with a first end-user device 104a among a plurality of end-user devices 104a-n. The first instruction may be received from the first end-user device 104a. The owner of the fine-grained privacy protection column is the only user permitted to perform DCL operations associated with that fine-grained privacy protection column.

[0028] The first instruction may include identification information, such as identification information for a specific fine-grained privacy-protected column and identification information for the user to whom the owner wants to grant predicate access. The first instruction may include operator information indicating one or more predicate operators that the user granted predicate access can use to query the fine-grained privacy-protected column. The first instruction may include control information indicating a limit on the number of times a user can query a specific fine-grained privacy-protected column using one or more predicate operators (e.g., the number of times a user can query a specific fine-grained privacy-protected column using one or more predicate operators). The control information in the first instruction may indicate a reset interval for the limit (e.g., a time interval at which the number of times a user can run a query containing (multiple) predicate operators is reset).

[0029] By comparing the identification and operator information in each existing row of the predicate directory table with the information associated with the first instruction, it can be determined whether any row in the predicate directory table matches the first instruction. If an existing row includes the same identification and operator information as indicated by the first instruction (e.g., associated with or included in the first instruction), then an existing row in the predicate directory table can match the first instruction.

[0030] In this embodiment, no existing row in the predicate directory table matches the first instruction. If the predicate directory table does not include any row containing the same identification and operator information as indicated by the first instruction, it can be determined that no existing row in the predicate directory table matches the first instruction. In response to determining that no match exists, DBMS 108 can create a new row in the predicate directory table. The new row can be created based on the first instruction. For example, the new row can be created based on the first instruction (such as the identification information, operator information, and control information indicated by the first instruction). The new row can be configured to control user access permissions to predicates on fine-grained privacy-protected columns.

[0031] In other embodiments, a match exists between an existing row in the predicate directory table and the first instruction. If the predicate directory table includes existing rows containing the same identification and operator information as indicated by the first instruction, a match can be determined between the existing row in the predicate directory table and the first instruction. In response to determining that a match exists, DBMS 108 can update the control information in the existing row of the predicate directory table based on the first instruction. For example, the control information in the existing row of the predicate directory table can be replaced with the control information indicated by the first instruction.

[0032] In an embodiment, rows in the predicate catalog table may include control information indicating the number of queries allowed by a particular predicate survivor user to query a specific fine-grained privacy-protected column using one or more specified predicate operators, as well as intervals with numeric values. Numeric values ​​can indicate any time period (e.g., one day, two days, one week, one month, etc.). If an interval in a row has a numeric value, it indicates that the quantity limit in that row will be reset when the time period expires or has expired. DBMS 108 may reset the quantity limit in a row at regular intervals in response to determining that an interval in a new row has a numeric (e.g., not null) value, regardless of whether the number of queries performed by a particular predicate survivor user has reached the quantity limit.

[0033] In an embodiment, rows in the predicate catalog table may include control information indicating the number of queries allowed by a particular predicate surviving user to a specific fine-grained privacy-protected column using one or more specified predicate operators, as well as intervals with null values. If an interval in a row is null, it indicates that the number of queries performed by that row will never be reset. If an interval in a row is null, and it is determined that the number of queries performed by a particular predicate surviving user has reached the number limit, DBMS108 may delete the row from the predicate catalog table instead of resetting the number limit.

[0034] A user's predicate access permissions to a fine-grained privacy-protected column can be revoked. For example, an owner might accidentally (e.g., incorrectly) grant a user predicate access permissions to a fine-grained privacy-protected column. In an embodiment, the owner of the fine-grained privacy-protected column might want to completely revoke a user's predicate access permissions to the fine-grained privacy-protected column. For example, the owner of the fine-grained privacy-protected column might want to revoke the user's ability to query the fine-grained privacy-protected column using any predicate operator.

[0035] To completely revoke a user's predicate access to a fine-grained privacy-protected column, the owner can send a second instruction (e.g., to DBMS108) to completely revoke the user's predicate access to the fine-grained privacy-protected column. The second instruction can be associated with the owner's identification information. The second instruction may include identification information, such as the identification information of the specific fine-grained privacy-protected column and the identification information of the user whose predicate access the owner wants to revoke. The second instruction may include operator information with null values, indicating that the owner wants to revoke the user's ability to query the fine-grained privacy-protected column using any predicate operator (not just a specific predicate operator).

[0036] In response to receiving the second instruction, DBMS 108 can identify all rows in the predicate directory table that match the identification information indicated by the second instruction. For example, DBMS 108 can identify all rows in the predicate directory table that include identification information matching the identification information indicated by the second instruction. If a row in the predicate directory table and the second instruction are associated with the same identifier for that fine-grained privacy protection column, the same identifier for the owner of that fine-grained privacy protection column, and the same identifier for the user, then that row can include identification information matching the identification information indicated by the second instruction. All matching rows can be deleted from the predicate directory table. Deleting all matching rows completely revokes the user's predicate access rights to the fine-grained privacy protection column.

[0037] In other embodiments, the owner of a fine-grained privacy column may want to revoke a user's predicate access rights to the fine-grained privacy column using only specific predicate operators. To revoke a user's predicate access rights to the fine-grained privacy column using only specific predicate operators, the owner may send a third instruction (e.g., to DBMS108) to revoke the user's predicate access rights to the fine-grained privacy column using specific predicate operators. The third instruction may be associated with the owner's identification information. The third instruction may include identification information, such as the identification information of the specific fine-grained privacy column and the identification information of the user whose predicate access rights the owner wants to revoke. The third instruction may include the specific predicate operator.

[0038] In response to receiving a third instruction, DBMS 108 may identify one or more rows in the predicate directory table that match the identification information indicated by the third instruction (e.g., associated with or included in the third instruction). For example, DBMS 108 may identify rows in the predicate directory table that include identification information matching the identification information indicated by the third instruction. If a row in the predicate directory table and the third instruction are associated with the same identifier of that fine-grained privacy protection column, the same identifier of the owner of that fine-grained privacy protection column, and the same identifier of the user (i.e., the predicate surviving user), then the row may include identification information matching the identification information indicated by the third instruction.

[0039] It can be determined whether the operator information of one row among the identified rows covers only the specific predicate operator. For example, it can be determined whether the operator information of one row among the identified rows exactly matches the specific predicate operator. If the operator information of one row among the identified rows covers only the specific predicate operator, that row can be deleted from the predicate directory table. Deleting that row can revoke a user's predicate access rights to the fine-grained privacy protection column using the specific predicate operator. Additionally or alternatively, if the operator information of one row among the identified rows is null, this indicates that the operator information of that row covers both the specific predicate operator and other predicate operators besides the specific predicate operator. If it is determined that the operator information in at least one row covers other predicate operators besides the specific predicate operator, the predicate directory table can be updated to cover only the other predicate operators. Updating the operator information in the predicate directory table to cover only the other predicate operators can revoke a user's predicate access rights to the fine-grained privacy protection column using the specific predicate operator.

[0040] Figure 2 An example system 200 for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns, according to this disclosure, is shown. System 200 includes a DBMS 108 and at least one database 110. DBMS 108 may be contained in encrypted private storage 206. DBMS 108 may communicate with at least one database 110 via shared storage 202.

[0041] DBMS 108 can support multiple fine-grained privacy protection applications 210. To achieve flexible data privacy, a fine-grained approach can be used to protect privacy at the column level. For example, an employee data table may contain sensitive information such as salary information. DBMS 108 must ensure that no other user (including the database administrator) other than the human resources role can view this content. DBMS 108 may include an SQL engine 207. The SQL engine 207 can receive commands (e.g., SQL commands) from end users (e.g., end-user devices 104a-n). In response to commands received from the end user, the SQL engine 207 can perform predicate access authorization 209 and revoke predicate access authorization 211.

[0042] DBMS108 can rely on a Trusted Execution Environment (TEE)-based Virtual Machine (VM) environment. TEE-based VM environments provide execution domain isolation through encryption of memory and registers, integrity measurements, and remote authentication to ensure data confidentiality. VM instances do not require additional development libraries or an operating system (OS) to support application workloads, thus saving engineering resources. Furthermore, VM instances can fully utilize all available CPU and memory resources on the physical node. This advantage helps manage large memory workloads entirely within secure memory, minimizing I / O operations and significantly improving performance.

[0043] Figure 3 An example predicate directory table 300 is shown. A DBMS (e.g., DBMS108) can create the predicate directory table 300. The predicate directory table 300 can be configured to control access to fine-grained privacy-preserving columns by predicate surviving users. Each predicate surviving user can be granted access to query at least one fine-grained privacy-preserving column using at least one predicate operator. The at least one predicate operator can include one or more of the following operators: = (e.g., equal to), > (e.g., greater than), < (e.g., less than), ≤ (e.g., less than or equal to), ≥ (e.g., greater than or equal to), "notin (not in)," "between (between)," "null (empty)," and / or any other operator.

[0044] Each row of the predicate directory table 300 may include identification information 301. The identification information 301 in each row of the predicate directory table 300 may include column ID information 302 for a specific fine-grained privacy-protected column, identification information 304 for the owner of the specific fine-grained privacy-protected column, and identification information 306 for a specific predicate survivor. Each row of the predicate directory table may include operator information 308. The operator information 308 may indicate one or more predicate operators that a predicate survivor can use to query a fine-grained privacy-protected column. Each row of the predicate directory table may include control information 305 for controlling access to a specific fine-grained privacy-protected column by a specific predicate survivor. The control information 305 in each row of the predicate directory table may include quantity limit information 310 indicating the number of times a specific predicate survivor is allowed to query a specific fine-grained privacy-protected column using one or more predicate operators (e.g., the number of times a predicate survivor is allowed to query a specific fine-grained privacy-protected column using one or more predicate operators). The control information 305 in each row of the predicate catalog table may include interval information 312 indicating a reset interval for a quantity limit (e.g., the time interval for resetting the number of times a user can run a query containing (multiple) predicate operators).

[0045] The owner of a fine-grained privacy column might want to grant a user predicate access to that column. The owner can send a first instruction. This first instruction can be associated with the owner's identification information (e.g., owner ID "user1"). The first instruction can include identification information. This identification information can include the identification information for the specific fine-grained privacy column (e.g., column ID "uid1"). The identification information can also include the identification information of the user to whom the owner wants to grant predicate access (e.g., predicate survivor ID "user2"). The first instruction can include operator information indicating one or more predicate operators that the user granted predicate access can use to query the fine-grained privacy column. For example, the operator information can include a "null" value, indicating that the user granted predicate access can use any available operator to query the fine-grained privacy column. The first instruction can include control information indicating a quantity limit (e.g., a quantity of "100") allowing the user to query the specific fine-grained privacy column using one or more predicate operators. The control information in the first instruction can indicate a reset interval for the quantity limit (e.g., a time interval of "1" days). The first instruction can instruct DBMS108 to grant user2 predicate access permissions to query column "uid1" 100 times per day using any available predicate operator.

[0046] In response to receiving a first instruction from the owner of the fine-grained privacy-preserving column, it can be determined whether any existing row in the predicate directory table 300 matches the first instruction. This can be determined by comparing the identification and operator information in each existing row of the predicate directory table 300 with the information associated with the first instruction. If an existing row in the predicate directory table 300 and the first instruction indicate the same identification and operator information, then that existing row can be considered a match for the first instruction.

[0047] If it is determined that there is no match between any existing row in the predicate index table 300 and the first instruction, a new row can be created in the predicate index table 300. Figure 4An example predicate directory table 300 is shown, which has been updated to include a new row 402 in response to determining that no existing row in the predicate directory table 300 matches the first instruction. The new row 402 may correspond to the first instruction. The new row 402 may be created based on the first instruction. For example, the new row 402 may be created based on information indicated by the first instruction (such as identification information, operator information, and control information indicated by the first instruction). For example, the new row 402 may be populated with column ID “uid1”, owner ID “user1”, predicate survivor ID “user2”, a “null” value covering all operators, quantity “100”, and time interval “1” (e.g., indicating “1” days).

[0048] The owner of a fine-grained privacy column might want to modify a user's predicate access permissions for the fine-grained privacy column associated with column ID "uid1" using all operators indicated by a "null" value. The owner can send a modified instruction. The modified instruction may include the same identification information as the first instruction (e.g., column ID "uid1" and predicate survivor ID "user2"). The modified instruction may include the same operator information as the first instruction (e.g., "null" value). The modified instruction may include different control information than the first instruction. This different control information may include different quantity limits and / or different intervals than the first instruction. This different control information could indicate, for example, a different quantity limit "1000" and a different time interval "15" days. The modified instruction could instruct DBMS108 to grant user2 predicate access permissions to query column "uid1" 1000 times every fifteen days (instead of 100 times per day) using any available predicate operator.

[0049] In response to receiving a modified instruction from the owner of the fine-grained privacy-preserving column, it can be determined whether any existing row in the predicate directory table 300 matches the modified instruction. This can be determined by comparing the identification and operator information in each existing row of the predicate directory table 300 with the information associated with the modified instruction. If an existing row in the predicate directory table 300 and the modified instruction indicate the same identification and operator information, then that existing row can be considered a match for the modified instruction.

[0050] If a match is found between an existing line in the predicate directory table 300 and the modified instruction, the control information 305 in the existing line can be updated in the predicate directory table 300. Figure 5An example predicate directory table 300 is shown, which has been updated in response to determining that a match exists between an existing line 402 in the predicate directory table 300 and a modified instruction. The existing line 402 can be updated to correspond to the modified instruction. For example, line 402 can be modified based on different control information contained in the modified instruction, such as different quantity limits and / or different time intervals. For example, control information 305 in the modified line 402 could reflect a different quantity limit “1000” and a different time interval “15” days.

[0051] like Figure 6 As shown, row 602 in the predicate catalog table 300 may include control information 305, which includes interval information 312 with null values. If the interval 312 is null, this indicates that the quantity limit indicated by the quantity limit information 310 in that row will never be reset. Row 602 may be deleted in response to determining that the number of queries performed by a particular predicate survivor user (e.g., a user associated with the predicate survivor ID "user3") has reached the quantity limit of 50.

[0052] like Figure 7 As shown, row 702 in the predicate catalog table 300 may include control information 305, which includes interval information 312 with non-null values ​​(e.g., numeric values). If the interval 312 is non-null, this indicates that the quantity limit indicated by the quantity limit information 310 in that row should be reset at regular intervals, regardless of whether the number of queries executed by a particular predicate surviving user has reached the quantity limit indicated by the quantity limit information 310. Figure 7 In the example, row 702 includes a quantity limit information 310 with a value of 30 runs and an interval information 312 with a value of one day. Therefore, a specific predicate survivor user (e.g., the user associated with the predicate survivor ID "user4") can query the fine-grained privacy-protected column associated with column ID "uid1" up to 30 times per day using any available operator. If a predicate survivor user (e.g., the user associated with the predicate survivor ID "user4") queries the fine-grained privacy-protected column associated with column ID "uid1" 30 times in a day, the quantity limit indicated by the quantity limit information 310 in row 702 can be modified to indicate that the predicate survivor user cannot query the fine-grained privacy-protected column associated with column ID "uid1" again for the rest of the day. When the day ends (e.g., when a new interval begins), the quantity limit indicated by the quantity limit information 310 in row 702 can be reset to 30.

[0053] In one embodiment, a user's predicate access permissions to fine-grained privacy-protected columns can be completely revoked. Figure 8Example predicate directory table 300 is shown, which has been modified to completely revoke predicate access permissions for the user associated with the predicate survivor ID "user5" to the fine-grained privacy-protected column associated with the column ID "uid1". The owner of the fine-grained privacy-protected column may want to revoke the user's ability to query the fine-grained privacy-protected column using any predicate operator. To completely revoke a user's predicate access permissions to the fine-grained privacy-protected column, the owner can send an instruction to completely revoke the user's predicate access permissions to the fine-grained privacy-protected column. This instruction may be associated with the owner's identification information (e.g., owner ID "user1").

[0054] This instruction may include identification information for a specific fine-grained privacy-protected column (e.g., column ID "uid1"). This instruction may include identification information for users whose predicate access permissions the owner wants to completely revoke (e.g., predicate survivor ID "user5"). This instruction may include operator information indicating null values, which instructs the owner to revoke the user's ability to query the fine-grained privacy-protected column using any predicate operator (not just a specific predicate operator).

[0055] In response to receiving the instruction, DBMS 108 can identify all rows in the predicate directory table 300 that match the identification information indicated by the instruction. For example, DBMS 108 can identify all rows in the predicate directory table 300 that include column ID "uid1" as identification information 302, owner ID "user1" as identification information 304, and predicate survivor ID "user5" as identification information 306. Figure 8 In the example, rows 802 and 804 both match the identification information indicated by the instruction. All matching rows (such as rows 802 and 804) can be deleted from the predicate catalog table 300. Deleting all matching rows completely revokes the user's predicate access to the fine-grained privacy-preserving column associated with column ID "uid1".

[0056] In one embodiment, a user's predicate access permissions to fine-grained privacy-protected columns can be partially revoked. Figure 9Example predicate directory table 300 is shown, which has been modified to partially revoke predicate access permissions for a user associated with the predicate survivor ID "user6" to a fine-grained privacy-protected column associated with column ID "uid1". The owner of the fine-grained privacy-protected column may want to revoke the user's ability to query the fine-grained privacy-protected column using a specific predicate operator (e.g., the operator "=") or any other specific predicate operator. To revoke a user's predicate access permissions to the fine-grained privacy-protected column, the owner can send an instruction to revoke the user's predicate access permissions to the fine-grained privacy-protected column using a specific operator (e.g., the operator "=") or any other specific operator. This instruction may be associated with the owner's identification information (e.g., owner ID "user1").

[0057] This instruction may include identification information for a specific fine-grained privacy-protected column (e.g., column ID "uid1"). This instruction may include identification information for users whose predicate access permissions the owner wants to completely revoke (e.g., predicate survivor ID "user6"). This instruction may include operator information with an "=" value, indicating that the owner wants to revoke the user's ability to query the fine-grained privacy-protected column using a specific predicate operator "=" or any other specific operator.

[0058] In response to receiving the instruction, DBMS108 can identify all rows in the predicate directory table 300 that match the identification information and operator information indicated by the instruction. For example, DBMS108 can identify all rows in the predicate directory table 300 that include column ID "uid1" as identification information 302, owner ID "user1" as identification information 304, predicate survivor ID "user6" as identification information 306, and "=" or "null (including "=") as operator 308.

[0059] exist Figure 9 In the example, line 904 (not line 902) matches the operator information included in the instruction. Line 902 does not match the operator information included in the instruction because line 902 includes an operator different from the specific predicate operator. Matching lines (such as line 904) can be deleted from predicate directory table 300. Deleting matching lines can revoke a user's predicate access permissions using the predicate operator "=" on the fine-grained privacy-protected column associated with column ID "uid1". Figure 9 In the example, line 902 will not be deleted because line 902 does not match the operator information included in the instruction.

[0060] Figure 10Another example of predicate directory table 300 is shown, which is modified to partially revoke predicate access permissions for a user associated with the predicate survivor ID "user7" to a fine-grained privacy-protected column associated with column ID "uid1". The owner of the fine-grained privacy-protected column may want to revoke the user's ability to query the fine-grained privacy-protected column using a specific predicate operator (e.g., the operator "=") or any other specific operator. To revoke a user's predicate access permissions to the fine-grained privacy-protected column, the owner can send an instruction to revoke the user's predicate access permissions to the fine-grained privacy-protected column using a specific operator (e.g., the operator "=") or any other specific operator. This instruction may be associated with the owner's identification information (e.g., owner ID "user1").

[0061] This instruction may include identification information for a specific fine-grained privacy-protected column (e.g., column ID "uid1"). This instruction may include identification information for users whose predicate access permissions the owner wants to completely revoke (e.g., predicate survivor ID "user7"). This instruction may include operator information indicating an "=" value or other values ​​(indicating any other specific predicate operator) that the owner wants to revoke the user's ability to query the fine-grained privacy-protected column using the specific predicate operator "=" or any other specific predicate operator.

[0062] In response to receiving the instruction, DBMS 108 can identify all rows in the predicate directory table 300 that match the identification information and operator information indicated by the instruction. For example, DBMS 108 can identify all rows in the predicate directory table 300 that include "uid1" as column ID information 302, "user1" as owner information 304, "user6" as predicate survivor information 306, and "=" or "null (including "=") as operator information 308.

[0063] exist Figure 10In the example, both rows 1002 and 1004 match the identification and operator information indicated by the instruction. Row 1002 matches the operator information included in the instruction because it includes an empty operator value, and an empty operator value includes all available operators (predicate operators other than "="). Row 1004 matches the operator information included in the instruction exactly because it includes the specific operator "=". In response to determining that row 1004 matches the identification and operator information indicated by the instruction exactly, row 1004 can be deleted from the predicate directory table 300. In addition to deleting row 1004, the predicate directory table 300 can also be updated by replacing row 1002 with rows 1006a through 1006m to reflect that the user associated with the predicate survivor ID "user7" has predicate access rights to the fine-grained privacy protection column using other predicate operators (e.g., all other predicate operators besides the "=" operator). For example, row 1002 can be deleted, and rows 1006a through 1006m can be added to the predicate catalog table 300. Each row in rows 1006a through 1006m can grant predicate access to fine-grained privacy-preserving columns to the user associated with the predicate survivor ID "user7" using one of the other predicate operators (e.g., all other predicate operators except the "=" operator).

[0064] Figure 11 The illustration depicts an example procedure 1100 for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns. Although in Figure 11 The operations are described as a series of operations, but those skilled in the art will understand that various embodiments may add, remove, reorder or modify the operations described.

[0065] At 1102, a predicate directory table (e.g., predicate directory table 300) can be configured. The predicate directory table can be configured to control access to fine-grained privacy-preserving columns by predicate survivors. Each predicate survivor can be granted access to query at least one fine-grained privacy-preserving column using at least one predicate operator.

[0066] Each row of the predicate directory table may include identification information (e.g., identification information 301). The identification information in each row of the predicate directory table may include identification information for a specific fine-grained privacy-protected column (e.g., column ID information 302), identification information for the owner of the specific fine-grained privacy-protected column (e.g., owner information 304), and identification information for a specific predicate survivor (e.g., predicate survivor information 306). Each row of the predicate directory table may include operator information indicating one or more predicate operators (e.g., operator information 308). Each row of the predicate directory table may include control information for controlling access to a specific fine-grained privacy-protected column by a specific predicate survivor (e.g., control information 305). The control information in each row of the predicate directory table may include information indicating a limit on the number of times a specific predicate survivor is allowed to query a specific fine-grained privacy-protected column using one or more predicate operators (e.g., the number of times a predicate survivor is allowed to query a specific fine-grained privacy-protected column using one or more predicate operators) (e.g., quantity limit information 310). The control information in each row of the predicate catalog table may include information indicating a number of reset intervals (e.g., the time interval for resetting the number of times a particular predicate survivor can run a query containing (multiple) predicate operators) (e.g., interval information 312).

[0067] At 1104, a first instruction may be received. The first instruction may include instructions to grant a user predicate access rights to one of the fine-grained privacy-protected columns. The first instruction may be received from the owner of the fine-grained privacy-protected column. The owner of the fine-grained privacy-protected column is the only user authorized to perform DCL operations associated with that fine-grained privacy-protected column. At 1106, a match may be determined by comparing the identification and operator information in the predicate directory table with the information associated with the first instruction. Determining whether a match exists may include determining whether any existing row in the predicate directory table matches the first instruction. If an existing row includes the same identification and operator information as indicated by the first instruction, then the existing row in the predicate directory table may match the first instruction.

[0068] In this embodiment, no existing row in the predicate directory table matches the first instruction. At 1106, a new row can be created in the predicate directory table. A new row can be created in the predicate directory table in response to determining that no match exists. A new row can be created in the predicate directory table based on the first instruction. For example, the new row can be created based on identification information, operator information, and control information indicated by the first instruction. The new row can be configured to control user access permissions to predicates in a fine-grained privacy-protected column.

[0069] Figure 12 The illustration depicts an example procedure 1200 for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns. Although in Figure 12 The operations are described as a series of operations, but those skilled in the art will understand that various embodiments may add, remove, reorder or modify the operations described.

[0070] At position 1202, a predicate directory table (e.g., predicate directory table 300) can be configured. The predicate directory table can be configured to control access to fine-grained privacy-preserving columns by predicate survivors. Each predicate survivor can be granted access to query at least one fine-grained privacy-preserving column using at least one predicate operator.

[0071] Each row of the predicate directory table may include identification information (e.g., identification information 301). The identification information in each row of the predicate directory table may include identification information for a specific fine-grained privacy-protected column (e.g., column ID information 302), identification information for the owner of the specific fine-grained privacy-protected column (e.g., owner information 304), and identification information for a specific predicate survivor (e.g., predicate survivor information 306). Each row of the predicate directory table may include operator information indicating one or more predicate operators (e.g., operator information 308). Each row of the predicate directory table may include control information for controlling access to a specific fine-grained privacy-protected column by a specific predicate survivor (e.g., control information 305). The control information in each row of the predicate directory table may include information indicating a limit on the number of times a specific predicate survivor is allowed to query a specific fine-grained privacy-protected column using one or more predicate operators (e.g., the number of times a predicate survivor is allowed to query a specific fine-grained privacy-protected column using one or more predicate operators) (e.g., quantity limit information 310). The control information in each row of the predicate catalog table may include information indicating a number of reset intervals (e.g., the time interval for resetting the number of times a particular predicate survivor can run a query containing (multiple) predicate operators) (e.g., interval information 312).

[0072] At 1204, a first instruction may be received. The first instruction may include instructions to grant a user predicate access to a fine-grained privacy column. The first instruction may be received from the owner of the fine-grained privacy column. The first instruction may be associated with the owner's identification information. The owner of the fine-grained privacy column is the only user authorized to perform DCL operations associated with that fine-grained privacy column. At 1206, a match may be determined by comparing the identification and operator information in the predicate directory table with the information associated with the first instruction. Determining whether a match exists may include determining whether any existing row in the predicate directory table matches the first instruction. If an existing row includes the same identification and operator information as indicated by the first instruction, then the existing row in the predicate directory table may match the first instruction.

[0073] In this embodiment, a match exists between an existing row in the predicate directory table and the first instruction. At 1208, control information in the existing row of the predicate directory table can be updated. The control information in the existing row of the predicate directory table can be updated in response to determining that a match exists between the identification information and operator information in the existing row of the predicate directory table and the information associated with the first instruction. The control information in the existing row of the predicate directory table can be updated based on the first instruction.

[0074] Figure 13 The illustration depicts an example procedure 1300 for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns. Although in Figure 13 The operations are described as a series of operations, but those skilled in the art will understand that various embodiments may add, remove, reorder or modify the operations described.

[0075] Rows in a predicate directory table (e.g., predicate directory table 300) may include control information (e.g., control information 305) indicating the number of queries allowed by a particular predicate surviving user using one or more specified predicate operators to a particular fine-grained privacy-protected column (e.g., number limit information 310) and intervals (e.g., interval information 312). At 1302, it can be determined whether the interval in the row is null. At 1304, it can be determined whether the number of queries executed by a particular predicate surviving user has reached the number limit indicated in the row. For example, it can be determined whether the user has executed the allowed number of queries. At 1306, a row can be deleted from the predicate directory table. The row can be deleted from the predicate directory table in response to determining that the interval in the row is null and that the number of queries executed by the user has reached the number limit. At 1308, the number limit can be reset at regular intervals in response to determining that the interval in the row is not null.

[0076] Figure 14 The illustration depicts an example procedure 1400 for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns. Although in Figure 14 The operations are described as a series of operations, but those skilled in the art will understand that various embodiments may add, remove, reorder or modify the operations described.

[0077] A user's predicate access permissions to a fine-grained privacy-protected column can be revoked. For example, an owner might accidentally (e.g., incorrectly) grant a user predicate access permissions to a fine-grained privacy-protected column. In an embodiment, the owner of the fine-grained privacy-protected column might want to completely revoke a user's predicate access permissions to the fine-grained privacy-protected column. For example, the owner of the fine-grained privacy-protected column might want to revoke the user's ability to query the fine-grained privacy-protected column using any predicate operator.

[0078] To completely revoke a user's predicate access to a fine-grained privacy-protected column, the owner can send a second instruction (e.g., to DBMS108) to completely revoke the user's predicate access to the fine-grained privacy-protected column. The second instruction can be associated with the owner's identification information. At 1402, a second instruction to completely revoke a user's predicate access to the fine-grained privacy-protected column can be received. The second instruction may include identification information, such as the identification information of the specific fine-grained privacy-protected column and the identification information of the user whose predicate access the owner wants to revoke. The second instruction may include operator information with null values, indicating that the owner wants to revoke the user's ability to query the fine-grained privacy-protected column using any predicate operator (not just a specific predicate operator).

[0079] At 1404, all rows in the predicate directory table (e.g., predicate directory table 300) that match the identifier of the fine-grained privacy column, the identifier of the owner of the fine-grained privacy column, and the user's identifier can be identified. This identification can be done in response to receiving a second instruction. At 1406, all identified rows can be deleted. Deleting all identified rows completely revokes the user's predicate access rights to the fine-grained privacy column.

[0080] Figure 15 The illustration depicts an example procedure 1500 for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns. Although in Figure 15 The operations are described as a series of operations, but those skilled in the art will understand that various embodiments may add, remove, reorder or modify the operations described.

[0081] A user's predicate access permissions to a fine-grained privacy-protected column can be revoked. For example, an owner might accidentally (e.g., incorrectly) grant a user predicate access permissions to a fine-grained privacy-protected column. In an embodiment, the owner of the fine-grained privacy-protected column might want to revoke a user's predicate access permissions to the fine-grained privacy-protected column using a specific predicate operator.

[0082] To revoke a user's predicate access permissions to a fine-grained privacy-protected column using a specific predicate operator, the owner can send a third instruction (e.g., to DBMS108) to revoke the user's predicate access permissions to the fine-grained privacy-protected column using a specific predicate operator. The third instruction may be associated with the owner's identification information. At 1502, a third instruction to revoke a user's predicate access permissions to a fine-grained privacy-protected column using a specific predicate operator can be received. The third instruction may include identification information, such as the identification information of the specific fine-grained privacy-protected column and the identification information of the user whose predicate access permissions the owner wants to revoke. The third instruction may include operator information indicating the specific predicate operator.

[0083] At 1504, at least one row in the predicate directory table (e.g., predicate directory table 300) that matches the identifier of the fine-grained privacy protection column, the identifier of the owner of the fine-grained privacy protection column, and the user's identifier can be identified. Identification of at least one row matching the identifier of the fine-grained privacy protection column, the identifier of the owner of the fine-grained privacy protection column, and the user's identifier can be performed in response to receiving a third instruction. At 1506, it can be determined whether the operator information of one row in the at least one row covers only the specific predicate operator. At 1508, one row in the at least one row can be deleted from the predicate directory table. Deletion of one row in the at least one row from the predicate directory table can be performed in response to determining that the operator information of one row in the at least one row covers only the specific predicate operator.

[0084] Figure 16 The illustration depicts an example procedure 1600 for implementing multi-level security control over predicate access to fine-grained privacy-preserving columns. Although in Figure 16 The operations are described as a series of operations, but those skilled in the art will understand that various embodiments may add, remove, reorder or modify the operations described.

[0085] A user's predicate access permissions to a fine-grained privacy-protected column can be revoked. For example, an owner might accidentally (e.g., incorrectly) grant a user predicate access permissions to a fine-grained privacy-protected column. In an embodiment, the owner of the fine-grained privacy-protected column might want to revoke a user's predicate access permissions to the fine-grained privacy-protected column using a specific predicate operator.

[0086] To revoke a user's predicate access permissions to a fine-grained privacy-protected column using a specific predicate operator, the owner can send a third instruction (e.g., to DBMS108) to revoke the user's predicate access permissions to the fine-grained privacy-protected column using a specific predicate operator. The third instruction may be associated with the owner's identification information. At 1602, a third instruction to revoke a user's predicate access permissions to a fine-grained privacy-protected column using a specific predicate operator can be received. The third instruction may include identification information, such as the identification information of the specific fine-grained privacy-protected column and the identification information of the user whose predicate access permissions the owner wants to revoke. The third instruction may include operator information indicating the specific predicate operator.

[0087] At 1604, at least one row in the predicate directory table (e.g., predicate directory table 300) that matches the identifier of the fine-grained privacy protection column, the identifier of the owner of the fine-grained privacy protection column, and the user's identifier can be identified. This identification can be made in response to receiving a third instruction. At 1606, it can be determined whether the operator information in one of the at least one rows covers other predicate operators besides the specific predicate operator. At 1608, the operator information in the at least one row can be updated to cover only other predicate operators. This update can be made in response to determining that the operator information in one of the at least one rows covers other predicate operators besides the specific predicate operator.

[0088] Figure 17 The illustration shows computing devices that can be used in various aspects, such as... Figure 1 and Figure 2 Used in the models, parts, and / or devices depicted herein. Regarding Figure 1 and Figure 2 Any or all components can be free. Figure 17 This is implemented using one or more instances of the computing device 1700. Figure 17 The computer architectures shown illustrate conventional server computers, workstations, desktop computers, laptop computers, tablet computers, network facilities, PDAs, e-readers, digital cellular phones, or other computing nodes, and can be used to perform any aspect of the computers described herein, such as implementing the methods described herein.

[0089] The computing device 1700 may include a substrate or “motherboard”, which is a printed circuit board on which multiple components or devices may be connected via a system bus or other electrical communication path. One or more central processing units (CPUs) 1704 may operate in conjunction with a chipset 1706. The CPUs 1704(multiple) may be standard programmable processors that perform arithmetic and logic operations required to perform the operation of the computing device 1700.

[0090] Multiple CPU 1704 processors can perform necessary operations by manipulating switching elements to transition from one discrete physical state to the next. These switching elements can distinguish and change these states. Switching elements typically include electronic circuitry (such as flip-flops) that holds one of two binary states, and electronic circuitry (such as logic gates) that provides an output state based on a logical combination of the states of one or more other switching elements. These basic switching elements can be combined to create more complex logic circuits, including registers, adder-subtractor units, arithmetic logic units, floating-point units, etc.

[0091] The (multiple) CPUs 1704 can be enhanced or replaced by other processing units (such as (multiple) GPUs 1705). The (multiple) GPUs 1705 may include processing units specifically designed for, but not necessarily limited to, highly parallel computing (such as graphics and other visualization-related processing).

[0092] Chipset 1706 provides an interface between CPU(s) 1704 and the remaining components and devices on the substrate. Chipset 1706 provides an interface to random access memory (RAM) 1708, which is used as main memory in computing device 1700. Chipset 1706 may also provide an interface to computer-readable storage media, such as read-only memory (ROM) 1720 or non-volatile RAM (NVRAM) (not shown), for storing basic routines that help boot computing device 1700 and transfer information between various components and devices. ROM 1720 or NVRAM may also store other software components required for the operation of computing device 1700 according to the various aspects described herein.

[0093] Computing device 1700 can operate in a networked environment using a logical connection via a local area network (LAN) to remote computing nodes and computer systems. Chipset 1706 may include functionality for providing network connectivity via a network interface controller (NIC) 1722 (such as a Gigabit Ethernet adapter). NIC 1722 enables computing device 1700 to connect to other computing nodes via network 1718. It should be understood that multiple NICs 1722 may be present in computing device 1700, thereby connecting the computing device to other types of networks and remote computer systems.

[0094] Computing device 1700 can be connected to mass storage device 1728, which provides non-volatile storage for the computer. Mass storage device 1728 can store system programs, application programs, other program modules, and data, which are described in more detail herein. Mass storage device 1728 can be connected to computing device 1700 via storage controller 1724, which is connected to chipset 1706. Mass storage device 1728 can consist of one or more physical storage units. Mass storage device 1728 may include management unit 1710. Storage controller 1724 can interface with physical storage units via a Serial Amount SCSI (SAS) interface, a Serial Advanced Technology Attachment (SATA) interface, a Fibre Channel (FC) interface, or other types of interfaces used for physical connections and data transfer between the computer and physical storage units.

[0095] The computing device 1700 can store data on the mass storage device 1728 by changing the physical state of the physical storage units to reflect the stored information. The specific changes in the physical state can depend on various factors and different implementations described herein. Examples of such factors may include, but are not limited to, the technology used to implement the physical storage units and whether the mass storage device 1728 is characterized as a primary or secondary storage device.

[0096] For example, computing device 1700 can issue instructions via storage controller 1724 to change the magnetic properties of a specific location within a disk drive unit, the reflection or refraction properties of a specific location within an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit, thereby storing information in mass storage device 1728. Other transformations of the physical medium are also possible without departing from the scope and spirit of this specification, wherein the foregoing examples are provided merely to assist this specification. Computing device 1700 can also read information from mass storage device 1728 by detecting the physical state or characteristics of one or more specific locations within a physical storage unit.

[0097] In addition to the mass storage device 1728 described above, the computing device 1700 can also access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. Those skilled in the art will understand that a computer-readable storage medium can be any available medium that provides non-transitory data storage and can be accessed by the computing device 1700.

[0098] By way of example and not limitation, computer-readable storage media may include volatile and non-volatile computer-readable storage media, transient computer-readable storage media and non-transitory computer-readable storage media, and removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM (“EPROM”), electrically erasable programmable ROM (“EEPROM”), flash memory or other solid-state memory technologies, compact disc ROM (“CD-ROM”), digital versatile optical disc (“DVD”), high-definition DVD (“HD-DVD”), BLU-RAY, or other optical storage devices, magnetic tape cassettes, magnetic tape, disk storage devices, other magnetic storage devices, or any other medium that can be used to store desired information in a non-transitory manner.

[0099] High-capacity storage devices (such as) Figure 17 The mass storage device 1728 depicted herein can store an operating system used to control the operation of the computing device 1700. The operating system may include a version of the LINUX operating system. The operating system may include a version of the WINDOWS SERVER operating system from Microsoft Corporation. Depending on other aspects, the operating system may include a version of the UNIX operating system. Various mobile phone operating systems, such as iOS and Android, may also be utilized. It should be understood that other operating systems may also be utilized. The mass storage device 1728 can store other systems, applications, and data used by the computing device 1700.

[0100] Mass storage device 1728 or other computer-readable storage media may also be encoded with computer-executable instructions that, when loaded into computing device 1700, transform the computing device from a general-purpose computing system into a special-purpose computer capable of implementing the various aspects described herein. These computer-executable instructions transform computing device 1700 by specifying state transitions of CPU(s) 1704, as described above. Computing device 1700 can access computer-readable storage media storing computer-executable instructions that, when executed by computing device 1700, can perform the methods described herein.

[0101] Computing devices (such as Figure 17The computing device 1700 depicted may also include an input / output controller 1732 for receiving and processing input from multiple input devices (such as a keyboard, mouse, touchpad, touchscreen, or electronic stylus) or other types of input devices. Similarly, the input / output controller 1732 may provide output to a display (such as a computer monitor, flat panel display, digital projector, printer, or plotter) or other types of output devices. It should be understood that the computing device 1700 may not include... Figure 17 All components shown may include Figure 17 Other components not explicitly shown in the document, or those that can be utilized with Figure 17 The architecture shown is completely different.

[0102] As described herein, a computing device can be a physical computing device, such as... Figure 17 The computing device 1700. A computing node may also include virtual machine host processes and one or more virtual machine instances. Computer-executable instructions can be indirectly executed by the physical hardware of the computing device by interpreting and / or executing instructions stored and executed in the context of a virtual machine.

[0103] It should be understood that these methods and systems are not limited to any particular method, component, or implementation. It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting.

[0104] Unless the context clearly specifies otherwise, the singular forms “a,” “an,” and “the” as used in this specification and the appended claims include a plural of indicators. A range may be expressed herein as from “about” a particular value, and / or to “about” another particular value. When such a range is expressed, another embodiment includes from one particular value and / or to another particular value. Similarly, when a value is expressed as an approximation using the antecedent “about,” it will be understood that the particular value forms another embodiment. It will also be understood that the endpoints of each range are significant relative to and independent of the other endpoints.

[0105] "Optional" or "optionally" means that the event or situation described below may or may not occur, and the description includes instances where the event or situation occurs or does not occur.

[0106] Throughout the description and claims of this specification, the word "comprise" and variations thereof (such as "comprising and components") mean "including but not limited to" and are not intended to exclude, for example, other components, integrals, or steps. "Exemplary" means "an example of..." and is not intended to convey indications of preferred or ideal embodiments. "Like" is not used in a limiting sense but for interpretive purposes.

[0107] Components that can be used to perform the described methods and systems are described. When describing combinations, subsets, interactions, groups, etc., of these components, it should be understood that while specific references to each of the various individual and collective combinations and arrangements of these components may not be explicitly described, each component is specifically conceived and described herein for all methods and systems. This applies to all aspects of this application, including but not limited to operations in the described methods. Therefore, if various additional operations exist that can be performed, it should be understood that each of these additional operations can be performed using any specific embodiment or combination of embodiments of the described methods.

[0108] The method and system can be more readily understood by referring to the following detailed description of preferred embodiments and examples included therein, as well as the accompanying drawings and their descriptions.

[0109] As will be understood by those skilled in the art, the methods and systems may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the methods and systems may take the form of a computer program product on a computer-readable storage medium having computer-readable program instructions (e.g., computer software) embodied within the storage medium. More specifically, the methods and systems may take the form of computer software implemented on the web. Any suitable computer-readable storage medium may be utilized, including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.

[0110] Embodiments of these methods and systems are described below with reference to block diagrams and flowcharts illustrating methods, systems, apparatuses, and computer program products. It should be understood that each block in the block diagrams and flowcharts, as well as combinations of blocks in the block diagrams and flowcharts, can be implemented by computer program instructions. These computer program instructions can be loaded onto a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute on the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart.

[0111] These computer program instructions may also be stored in a computer-readable storage medium, which may instruct a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of writing comprising computer-readable instructions for implementing the functions specified in one or more boxes of a flowchart. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more boxes of a flowchart.

[0112] The various features and processes described above can be used independently of each other or combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. Additionally, in some embodiments, certain method or process blocks may be omitted. The methods and processes described herein are not limited to any particular order, and blocks or states associated with these methods and processes may be performed in other suitable orders. For example, described blocks or states may be performed in an order different from that specifically described, or multiple blocks or states may be combined in a single block or state. Example blocks or states may be performed serially, in parallel, or in some other manner. Blocks or states may be added to or removed from the described example embodiments. The example systems and components described herein may be configured differently than described. For example, elements may be added, removed, or rearranged compared to the described example embodiments.

[0113] It should also be understood that the items are illustrated as being stored in memory or storage devices during use, and that these items, or portions thereof, may be transferred between memory and other storage devices for memory management and data integrity purposes. Alternatively, in other embodiments, some or all of the software modules and / or systems may be executed in memory on another device and communicate with the illustrated computing system via inter-computer communication. Furthermore, in some embodiments, some or all of the systems and / or modules may be implemented or provided in other ways, such as at least in part as firmware and / or hardware, including but not limited to one or more application-specific integrated circuits (“ASICs”), standard integrated circuits, controllers (e.g., by executing appropriate instructions, and including microcontrollers and / or embedded controllers), field-programmable gate arrays (“FPGAs”), complex programmable logic devices (“CPLDs”), etc. Some or all of the modules, systems, and data structures may also be stored (e.g., as software instructions or structured data) on computer-readable media, such as hard disks, memory, networks, or portable media articles to be read by appropriate devices or via appropriate connections. The system, modules, and data structures can also be transmitted as generated data signals (e.g., as part of a carrier or other analog or digital propagation signal) over various computer-readable transmission media, including wireless and wired / cable-based media, and can take various forms (e.g., as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). In other embodiments, such a computer program product can also take other forms. Therefore, the invention can be practiced with other computer system configurations.

[0114] Although the methods and systems have been described in conjunction with preferred embodiments and specific examples, this is not intended to limit the scope to the specific embodiments illustrated, as the embodiments herein are intended to be illustrative rather than restrictive in all respects.

[0115] Unless otherwise expressly stated, this document does not imply that any method described herein requires its operations to be performed in a particular order. Therefore, no order is intended to be inferred where the method claims do not actually describe the order of their operations, or where the claims or specification do not otherwise specifically state that the operations are limited to a particular order. This applies to any possible non-express basis for interpretation, including: logical questions concerning the arrangement of steps or the flow of operations; direct meanings derived from grammatical organization or punctuation; and the number or type of embodiments described in the specification.

[0116] It will be apparent to those skilled in the art that various modifications and variations can be made without departing from the scope or spirit of this disclosure. Other embodiments will be apparent to those skilled in the art in light of the description and practice described herein. This specification and example figures are to be considered exemplary only, and the true scope and spirit are indicated by the appended claims.

Claims

1. A method of enforcing multi-security level control on predicate access to fine-grained privacy-protected columns, the method comprising: configuring a predicate catalog table for controlling predicate survivor user access to fine-grained privacy-protected columns, wherein each of the predicate survivor users is authorized to query at least one of the fine-grained privacy-protected columns using at least one predicate operator, and wherein each row of the predicate catalog table includes identification information, operator information indicating one or more predicate operators, and control information for controlling access of a particular predicate survivor user to a particular fine-grained privacy-protected column; receiving, from an owner of one of the fine-grained privacy-protected columns, a first instruction to grant a user predicate access rights to the one of the fine-grained privacy-protected columns; determining, based on comparing the identification information and the operator information in the predicate catalog table with information indicated by the first instruction, whether there is a match; and in response to determining that there is no match, creating a new row in the predicate catalog table based on the first instruction, wherein the new row is configured to control the user’s predicate access rights to the one of the fine-grained privacy-protected columns.

2. The method of claim 1, further comprising: in response to determining that there is a match between identification information and operator information in an existing row of the predicate catalog table and the information indicated by the first instruction, updating the control information in the existing row of the predicate catalog table based on the first instruction.

3. The method of claim 1, wherein the identification information in each row of the predicate catalog table includes information identifying the particular fine-grained privacy-protected column, identifying an owner of the particular fine-grained privacy-protected column, and identifying the particular predicate survivor user, and wherein the control information in each row of the predicate catalog table includes a quantity limit for allowing the particular predicate survivor user to query the particular fine-grained privacy-protected column using the one or more predicate operators, and a reset interval for the quantity limit.

4. The method of claim 1, further comprising: determining whether an interval in the new row has a null value; and determining whether a number of queries performed by the user reaches the quantity limit in the new row.

5. The method of claim 4, further comprising: in response to determining that the interval in the new row has a null value and the number of queries performed by the first user reaches the quantity limit, deleting the new row from the predicate catalog table.

6. The method of claim 4, further comprising: in response to determining that the interval in the new row has a non-null value, resetting the quantity limit at every interval.

7. The method of claim 1, further comprising: receiving a second instruction to completely revoke the user’s predicate access rights to the one of the fine-grained privacy-protected columns; identifying all rows that match an identifier of the one of the fine-grained privacy protected columns, an identifier of the owner of the one of the fine-grained privacy protected columns, and an identifier of the user; and deleting all the rows to completely revoke predicate access rights of the user to the one of the fine-grained privacy protected columns.

8. The method of claim 1, further comprising: receiving a third instruction to revoke predicate access rights of the user to the one of the fine-grained privacy protected columns using a particular predicate operator; identifying at least one row that matches an identifier of the one of the fine-grained privacy protected columns, an identifier of the owner of the one of the fine-grained privacy protected columns, and an identifier of the user.

9. The method of claim 8, further comprising: determining whether operator information in one of the at least one row only encompasses the particular predicate operator; and in response to determining that the operator information in the one of the at least one row only encompasses the particular predicate operator, deleting the one of the at least one row from the predicate catalog table.

10. The method of claim 8, further comprising: determining whether operator information in the at least one row encompasses predicate operators other than the particular predicate operator; and in response to determining that the operator information in the at least one row encompasses predicate operators other than the particular predicate operator, updating the operator information in the at least one row to only encompass the other predicate operators.

11. A system to implement multi-security level control on predicate access to fine-grained privacy protected columns, the system comprising: at least one processor; and at least one memory communicatively coupled to the at least one processor and comprising computer readable instructions that, when executed by the at least one processor, cause the at least one processor to perform the method of any one of claims 1-10.

12. A non-transitory computer readable storage medium having computer readable instructions stored thereon that, when executed by a processor, cause the processor to perform the method of any one of claims 1-10.

Images