A database access control method, device and medium

Abstract

The application discloses a database access control method, device and medium, and relates to the technical field of database access control. The method comprises the following steps: in response to a data writing request of writing a first data row into a database, determining a row attribute of the first data row, and storing sensitive column plaintext in the first data row according to a preset attribute base encryption strategy, the row attribute and system public parameters; in response to an access request of a current access user to the database, executing a row-level security strategy to determine a second data row visible to the current access user; identifying an attribute base encryption column in the second data row; obtaining a user private key of the current access user, and using the user private key to decrypt a data encryption key encapsulated in the attribute base encryption column; if the decryption is successful, using the data encryption key to decrypt sensitive column ciphertext in the attribute base encryption column, obtaining sensitive column plaintext and returning the sensitive column plaintext to the current access user.

Description

Technical Field

[0001] This application relates to the field of database access control technology, and in particular to a database access control method, device and medium. Background Technology

[0002] In enterprise data management, e-government, financial systems, and multi-tenant data platforms, a common scenario is that a single business table needs to restrict user access to certain data rows based on criteria such as organization, department, tenant, and region, while also requiring encryption protection for sensitive fields such as contract amounts, bank accounts, payroll information, and identity information. Traditional database row-level security mechanisms typically focus on solving the problem of "which data rows a user can see," while column-level sensitive data protection often relies on column permissions, de-identification rules, application-side encryption / decryption, or independent key management logic.

[0003] In existing technologies, one approach combines database row-level security mechanisms with application-side field encryption. However, this approach essentially relies on the database handling row-level filtering, while the application system or external encryption module handles sensitive field encryption and decryption. When user roles, departments, tenants, regions, or other business attributes change, it's crucial to ensure that both the database row-level security policy and application-side decryption authorization are updated synchronously. Otherwise, inconsistencies may arise, such as a user being able to see a row but not being able to decrypt it correctly, or the application declaring it decryptable when database row permissions have changed. Another approach involves built-in database encryption functions or plugins. This approach typically provides encryption and decryption capabilities through database functions, extended types, or plugin interfaces, with users explicitly calling the relevant functions during insertion or querying. However, this approach still struggles to fully address the issue of coordinated execution of row-level security and attribute-based encryption within database access control. Summary of the Invention

[0004] This application provides a database access control method, device, and medium to solve the following technical problem: how to enable the database to simultaneously complete row-level visibility control and column-level decryptability control during the access process, and realize the encrypted storage and controlled decryption of sensitive column data.

[0005] In a first aspect, embodiments of this application provide a database access control method, the method comprising: in response to a data write request to write a first data row into the database, determining the row attribute of the first data row, and encrypting and storing the plaintext of a sensitive column in the first data row according to a preset attribute-based encryption strategy, the row attribute and system parameters, wherein the system parameters are generated by an external authorization center and registered to the database; In response to the current user's access request to the database, a row-level security policy is executed to determine the second data row that is visible to the current user; Identify the attribute-based encryption column in the second data row; Obtain the user's private key of the currently accessing user, and use the user's private key to decrypt the data encryption key encapsulated in the attribute base encryption column; If decryption is successful, the ciphertext of the sensitive column in the attribute base encryption column is decrypted using the data encryption key to obtain the plaintext of the sensitive column, and the plaintext of the sensitive column is returned to the current accessing user.

[0006] Secondly, embodiments of this application also provide a database access control device, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a database access control method as described above.

[0007] Thirdly, embodiments of this application also provide a computer storage medium storing computer-executable instructions, which, when executed, implement a database access control method as described above.

[0008] The database access control method, device, and medium provided in this application have the following beneficial effects: In this embodiment, row-level security and attribute-based encryption are integrated into the database access control process. Preset attribute-based encryption policies, row attributes, and system parameters can be used to encrypt and store the plaintext of sensitive columns in the first data row. Furthermore, since the database first performs row-level filtering and then attribute-based decryption control on sensitive columns in visible rows, even if a user can access a data row, they may not necessarily obtain the plaintext of the sensitive fields in that row, thus achieving controlled decryption of the encrypted sensitive columns. In this way, the above method solves the problem in the prior art where row-level visibility and column-level decryptability cannot be executed in a coordinated manner, providing finer-grained data access control capabilities on the database side while ensuring database storage security and good database performance. Attached Figure Description

[0009] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart of a database access control method provided in this application embodiment; Figure 2 A schematic diagram of an initialization phase processing flow provided in an embodiment of this application; Figure 3This application provides a schematic diagram illustrating the process by which user attributes enter the database access control system from an external business system. Figure 4 A schematic diagram illustrating the process of establishing an association between an attribute-based encryption strategy and a sensitive column, as provided in an embodiment of this application; Figure 5 This is a schematic diagram illustrating the process of inserting data into a data table containing attribute-based encrypted columns, as provided in an embodiment of this application. Figure 6 A schematic diagram illustrating the execution process of a row-level security policy provided in an embodiment of this application; Figure 7 A schematic diagram illustrating a process for querying data containing an attribute-based encrypted column, provided in an embodiment of this application; Figure 8 A schematic diagram illustrating a process for updating data in an attribute-based encrypted column, as provided in an embodiment of this application; Figure 9 A schematic diagram illustrating the process of deleting data containing attribute-based encrypted columns, provided in an embodiment of this application; Figure 10 A schematic diagram illustrating the process of issuing and using a user's private key, provided as an embodiment of this application; Figure 11 A schematic diagram illustrating the overall principle of a database access control method provided in this application embodiment; Figure 12 This is a schematic diagram of the internal structure of a database access control device provided in an embodiment of this application. Detailed Implementation

[0010] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0011] Database access control typically includes capabilities such as authentication, object permissions, row-level security, column permissions, data masking, and audit trails. Taking PostgreSQL / Postgres compatible databases or other enterprise-level databases as examples, row-level security mechanisms allow the database to filter data rows during query, update, and delete operations based on the current user's identity, session context, organizational relationship, or business attributes, thereby controlling which records a user can access. This mechanism is suitable for solving problems related to multi-tenant isolation, departmental data isolation, regional data isolation, and organizational hierarchical authorization.

[0012] However, in enterprise business systems, data security requirements typically extend beyond simply whether a particular row is visible. A single business table often contains both ordinary business fields and highly sensitive fields such as amounts, account numbers, salaries, identity information, and sensitive contract clauses. A user may have permission to view the basic information of a row, but not necessarily all the sensitive columns within that row. For example, business personnel may see the contract number, contract status, and department, but may not be able to view the contract amount, bank account number, or sensitive information about the other party. Therefore, database access control needs to further address the question of whether sensitive columns in visible rows can be decrypted and returned in plaintext.

[0013] Existing databases typically achieve a certain level of sensitive field protection through column permissions, views, masking functions, triggers, application-side encryption / decryption, or external key management systems. While these methods are applicable to static permission scenarios, they often suffer from problems such as scattered configurations, limited expressive power, difficulty in policy reuse, and complex permission synchronization when permission conditions are dynamically related to user attributes, organizational attributes, and data row attributes. Especially when access conditions for the same sensitive field depend not only on the user's role but also on the user's department, the department to which the data belongs, the tenant identifier, the region identifier, or other business attributes, simple column permissions or fixed masking rules are insufficient to accurately express such fine-grained access requirements.

[0014] Attribute-based encryption is a type of encryption mechanism centered on attributes and access policies. Its basic idea is that data encryption is tied to an access policy; the user key is associated with a set of user attributes, and decryption is only possible when the user attributes satisfy the access policy. This mechanism is suitable for describing security requirements where "only users with certain attributes can decrypt certain types of data," and therefore can be used to enhance the ciphertext protection capabilities of sensitive database columns. Compared to schemes that rely solely on database permissions or application logic, attribute-based encryption can solidify access conditions into the ciphertext or key system, ensuring that even when sensitive data is stored in ciphertext form, decryption is only possible after the attribute policy is satisfied.

[0015] However, directly introducing attribute-based encryption into a database system is not straightforward. Databases already possess row-level security, user context, permission checks, query execution, and data type systems; attribute-based encryption involves elements such as public parameters, master keys, user attribute sets, user private keys, access policies, and ciphertext encapsulation. If these are implemented separately, row-level security policies and attribute-based encryption policies may each maintain a separate set of user attributes, requiring business systems to adapt to both the database permission model and the encryption authorization model. This can easily lead to problems such as inconsistent attribute sources, asynchronous authorization states, duplicate policy expressions, complex access paths, and high application modification costs.

[0016] In domestic substitution, enhanced databases for information technology innovation, government data platforms, financial systems, and enterprise multi-tenant systems, technology integrators typically aim to consolidate more security capabilities for unified execution at the database level. This reduces redundant modifications to business systems in terms of SQL queries, data writing, permission checks, and sensitive field handling, and also facilitates unified auditing and maintenance at the database level. However, if row-level security is still handled separately by the database, while sensitive column encryption is handled by application systems, gateway services, or independent encryption modules, the access control chain will be split into multiple stages. Furthermore, semantic inconsistencies or untimely updates can easily occur when user attributes are synchronized, converted, and interpreted across different systems.

[0017] Common existing processing methods include: 1. Use only database row-level security mechanisms to filter data rows based on user identity, session variables, or business attributes; 2. Control the return results of sensitive fields using only database column permissions, views, or desensitization functions; 3. Sensitive fields are encrypted and decrypted at the application layer, and the database only stores the encrypted field values; 4. Data keys are managed through an external key management system, with applications or middleware calling encryption / decryption interfaces during read / write operations; 5. Provide encryption functions in database extensions or plugins, allowing SQL to explicitly call encryption, decryption, or de-identification functions; 6. Store user attributes, role relationships, and organizational relationships in the business system, and have the business system construct filtering conditions or perform permission checks before accessing the database; 7. Deploy an independent attribute-based encryption authorization center, where the application system maintains the user attribute set and requests user private keys; 8. Configure row-level access control and column-level encryption control in different modules, and let the application system coordinate the execution order of the two.

[0018] These solutions can achieve row filtering or field encryption in some scenarios, but they usually cannot simultaneously meet requirements such as "coordinated execution of row-level security and column-level ciphertext protection", "unified source of user attributes", "reusable attribute policies", "transparent processing of sensitive column encryption and decryption on the database side" and "master key not being directly stored by the database".

[0019] From the perspective of access control consistency, the above solutions also have certain limitations. When using only row-level security mechanisms, a user who can see a row may access sensitive fields within that row through a normal query path; using only column permissions or de-identification functions makes it difficult to express complex attribute combinations; application-side encryption schemes increase the intrusion of business code, and different applications may implement different permission judgment logic; while external encryption modules can enhance ciphertext protection, if they cannot share user attributes and execution flows with the database row-level security mechanism, it is still difficult to avoid redundant configuration and permission fragmentation. Therefore, a database access control mechanism that integrates row-level security and attribute-based encryption is needed, enabling row-level visibility judgment and column-level decryptability judgment to be completed collaboratively during database access.

[0020] In existing technologies, there exists a database row-level security mechanism combined with application-side field encryption. Its typical steps are as follows: 1. The business system or database administrator creates a row-level security policy in the database; 2. When querying, updating, or deleting data, the database filters data rows based on the current user identity, session context, or business attributes; 3. Before writing sensitive fields, the business system calls the application-side encryption logic or an external encryption service to encrypt the field values; 4. The database saves the encrypted fields as ordinary fields; 5. When a user queries data, the database first returns the visible rows according to the row-level security policy; 6. The business system or middleware then determines whether sensitive fields can be decrypted based on its own maintained permission rules; 7. If access is granted, the key management system or encryption / decryption interface is invoked to decrypt the field value; 8. If access is not allowed, the application will return a de-identified value, an empty value, or an error message.

[0021] The essence of this solution is that the database handles row-level filtering, while the application system or external encryption module handles the encryption and decryption of sensitive fields. Its advantage is that it can achieve a certain level of row-level access control and field encryption protection without significantly modifying the database kernel. However, its disadvantage is that row-level security policies and field decryption policies are usually maintained by different systems, and user attributes may also be stored separately in the database, application system, or external permission center. When user roles, departments, tenants, regions, or other business attributes change, it is necessary to ensure that the database row-level security policy and application-side decryption authorization are updated synchronously. Otherwise, inconsistencies may arise, such as a user being able to see a row but not being able to decrypt it correctly, or the application side recognizing it as decryptable but the database row permissions having changed.

[0022] Furthermore, this approach typically requires application systems to explicitly participate in the encryption and decryption process of sensitive fields. For existing business systems, this may involve SQL rewriting, data access layer modifications, field type adaptation, key interface calls, exception handling, and adjustments to desensitization logic. Different business systems may also use different encryption / decryption methods and permission judgment methods for the same type of sensitive data, thereby increasing the difficulty of subsequent operation, maintenance, and auditing. In multi-system, multi-tenant, or multi-organizational scenarios, this problem will be further amplified.

[0023] Another similar approach is the "database built-in encryption function or plugin scheme." This scheme typically provides encryption and decryption capabilities through database functions, extended types, or plugin interfaces, with users explicitly calling the relevant functions during insertion or querying. While this approach can reduce some application-side encryption logic, ordinary encryption functions usually only address how to encrypt and decrypt field values, and do not inherently solve problems such as how to uniformly manage user attributes, how row-level security policies share attributes, how column-level decryption policies are combined with row attribute expressions, how user private keys are associated with attribute sets, and how master keys are stored by an external authorization center. Therefore, this type of scheme still struggles to fully address the issue of coordinating row-level security and attribute-based encryption in database access control.

[0024] To address the aforementioned problems, this application provides a database access control method. The technical solution proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0025] Figure 1 This is a flowchart illustrating a database access control method provided in an embodiment of this application. The method is executed by the database; specifically, it can be executed by a database server (i.e., database management system software). Figure 1 As shown in the figure, the database access control method provided in this application embodiment specifically includes the following steps: Step 101: In response to the data write request to write the first data row to the database, determine the row attribute of the first data row, and encrypt and store the plaintext of the sensitive columns in the first data row according to the preset attribute-based encryption strategy, the row attribute and system parameters.

[0026] The system parameters are generated by an external authorization center and registered in the database.

[0027] In this embodiment of the application, the aforementioned external authorization center also generates and stores a master key, which is not entered into the aforementioned database.

[0028] In one possible implementation, the method further includes: Once the database has completed initialization and the system parameters have been registered, a user attribute table is created or accessed, and fields that can be used as access control attributes are identified by attribute tagging. The database creates an attribute-based encryption policy, which is then bound to a specified business table or column.

[0029] In practical applications, the system parameters for registration refer to the system parameters generated by the external authorization center that the database receives and stores, so that they can be used as global parameters for subsequent attribute-based encryption and decryption operations. In other words, the system parameters provided by the external authorization center are imported into the system configuration.

[0030] In one possible implementation, when using a large attribute space attribute base encryption mechanism, the system common parameter is decoupled from the specific attribute set; when adding an access control attribute or adding an attribute value, it is not necessary to regenerate or update the system common parameter.

[0031] Figure 2 The diagram illustrates the processing flow during the initialization phase. First, the external authorization center generates the system parameters (system common parameters) and master key required for the attribute-based encryption system. The system parameters are used for subsequent encryption and policy binding, while the master key is used to generate user private keys and is stored by the external authorization center. Then, the database completes initialization and registers the system parameters provided by the external authorization center. The attribute-based encryption scheme described above supports a large attribute space. The system parameters are generated and registered to the database once during initialization. When new access control attributes are added subsequently, such as adding a division of labor attribute in addition to department and team attributes, it is not necessary to regenerate the system parameters or re-register in the database; the new attribute only needs to be referenced in the new policy, thus achieving dynamic attribute expansion.

[0032] Next, the database creates or accesses a user attribute table and identifies which fields can be used as access control attributes through attribute tagging. Furthermore, the database creates an attribute-based encryption policy and defines sensitive columns as attribute-based encryption columns when creating business tables, thus binding sensitive columns to the corresponding policy.

[0033] In one possible implementation, when the user attributes of the first user in the external business system are inserted or updated, the user attributes of the first user in the user attribute table are updated synchronously, and the attribute set of the first user is constructed based on the fields marked as access control attributes in the user attributes of the first user and their field values. The attribute set of the first user is used for the row-level security policy determination of the first user and is submitted to the external authorization center. The external authorization center generates the user private key of the first user based on the master key stored in the external authorization center and the attribute set of the first user.

[0034] Figure 3 This diagram illustrates the process by which user attributes enter the database access control system from an external business system. In practical applications, the external business system is responsible for designing and maintaining business users, while the database manages user attributes that can be used for row-level security and attribute-based encryption. User attributes may include roles, departments, tenants, regions, positions, or other business attributes; the specific attribute type is determined by the implementation scenario.

[0035] The database identifies attribute fields in the user attribute table through attribute type tags. When a user attribute is inserted or updated, the database constructs a corresponding attribute set for the user based on the tagged attribute fields and their values. This attribute set can be used for row-level security policy judgment or submitted to an external authorization center during the key distribution process. The external authorization center generates a user private key based on its stored master key and the received user attribute set. The user private key can be managed by the external authorization center, the client, the database security component, or other security carriers according to the specific deployment method.

[0036] Through the steps described above, row-level security and attribute-based encryption no longer maintain separate, unrelated attribute systems. Instead, they form a unified attribute source based on user attributes identifiable by the database. This reduces the problem of inconsistent attribute semantics for the same user across different access control modules.

[0037] When a user's attributes (such as department or role) change in an external business system, the database will promptly update the user attribute table it maintains. Then, it will find all fields marked as "access control attributes" in this table and combine them into an attribute set (e.g., {Department: Finance Department, Role: Accountant}). This set will be used for subsequent row-level security policy judgment and attribute-based encryption key generation. For example, an external business system could be a company's human resources system, responsible for managing employee information, including name, employee ID, department, and position. The database stores business data (such as payroll and project tables). Changes in user attributes in the external business system can occur through insertions, such as when a new employee, A, joins the company and the HR system creates a record for him: {name:A, department:Finance, role:Accountant, level:L2}. Updates can occur when employee B is transferred from the marketing department to the sales department, and the HR system changes his department from marketing to sales. The database has a dedicated user attribute table to store user attributes synchronized from the external system. When changes occur in the external business system, the database can synchronize in real time, listening for change events and updating immediately. Alternatively, it can synchronize periodically, fetching full or incremental data at regular intervals. After synchronization, the records corresponding to A and B in the user attribute table are updated: A: A new record is added, user_id=ZS001, department=Finance, role=Accountant, level=L2; B: user_id=LS002, department changed from marketing to sales.

[0038] The database pre-marks which fields in the user_attributes table are "access control attributes" using attribute type tags (such as field comments or system table configuration). Let's assume the department, role, and level fields are marked.

[0039] Once user attributes are synchronized, the database iterates through the marked fields, extracting field names and values ​​for each user and assembling them into a key-value pair set (i.e., an attribute set). For example, A's attribute set might be: {department:Finance, role:Accountant, level:L2}; B's attribute set might be: {department:Sales, role:Manager, level:L3}. This attribute set can be used for row-level security policy judgment (e.g., if the row-level security policy only allows viewing data within the department, the database can extract A's `department` value and compare it with the `dept` field of the data row). Alternatively, it can be submitted to an external authorization center to generate a private key: the database sends A's attribute set {department:Finance, role:Accountant, level:L2} to the external authorization center, which uses the master key (MK) to generate A's ABE user private key, embedding the aforementioned attributes within the private key.

[0040] In one possible implementation, the expression of the attribute-based encryption strategy references the user attributes or row attributes in the data rows managed by the database to describe the column-level decryption conditions of the sensitive column; The metadata of the attribute-based encryption policy includes the policy expression, policy identifier, and return rule.

[0041] In one possible implementation, the method further includes: In response to the second user's business table creation request, the target field is defined as an attribute-based encryption column according to the attribute-based encryption type specified in the business table creation request, and the target field is bound to the attribute-based encryption policy corresponding to the created policy identifier according to the policy identifier specified in the business table creation request.

[0042] Figure 4 This illustrates the process of establishing a relationship between an attribute-based encryption policy and a sensitive column. The database provides the ability to create attribute-based encryption policies, where policy expressions describe the column-level decryption conditions for sensitive columns. These conditions can reference user attributes managed by the database or row attributes within a data row. For example, the decryption condition for a sensitive column could be expressed as: the current user has the specified role, and the current user's department matches the department of this row.

[0043] After creating an attribute-based encryption policy, the database saves metadata such as the policy expression, policy identifier, and return rules, and returns the corresponding policy identifier. When creating a business table, users can define sensitive fields as attribute-based encryption types and bind these fields to existing attribute-based encryption policies. In other words, when creating the table, a field can be marked as protected by attribute-based encryption, and the database can be told which policy to use to determine who can decrypt the content of this field.

[0044] The database knows that the field is protected and which column-level decryption strategy should be applied when inserting, updating, or querying the field. The database automatically encrypts during writes and automatically decrypts according to the strategy during reads. The entire process is transparent to the user, and the strategy can be managed and reused independently.

[0045] Specifically, when creating or modifying a business table, users explicitly specify which existing policy identifier to bind to the sensitive column using DDL statements (such as `salary ABE_NUM(POLICY='P1001')`) or system stored procedures. After receiving the user's declaration, the database verifies whether the policy identifier exists and whether the attributes referenced by the policy expression are resolvable. If the verification passes, the database writes the binding relationship to metadata (such as the system directory or sensitive column binding table), permanently recording "column of table X is bound to policy Y". Once the binding relationship is established, in all subsequent write, read, and update operations, the database automatically retrieves the corresponding policy expression based on the policy identifier in the metadata and performs ABE encapsulation or decryption without further user intervention. The above binding relationship can record field data types, policy identifiers, user attributes referenced by the policy, row attribute source fields, and decryption failure response rules.

[0046] Attribute-based encryption types can be categorized based on the type of business field, such as text, numeric, date, or other types supported by the database. For example, ABE_TEXT is suitable for text-sensitive columns (such as name, remarks, contract terms), where the encrypted data is a byte stream of variable length; ABE_NUM is suitable for numeric-sensitive columns (such as salary, amount, age), where the encrypted data is a fixed-length byte block that retains sorting capability depending on the encryption mode; and ABE_DATE is suitable for date-sensitive columns (such as birthday, contract expiration date), where the encrypted data is the result of date serialization.

[0047] In practice, the internal storage format of attribute-based encryption types can include the ciphertext of sensitive columns, the encryption key for the encrypted data, the policy identifier, and necessary encrypted metadata. This internal format remains relatively transparent to upper-layer business logic, allowing users to design table structures and access data in a manner similar to ordinary fields. That is, when users insert data, they still write it in plaintext, and the database automatically encrypts it according to the policy; during queries, the database automatically decrypts it, and the user reads the plaintext.

[0048] By unifying the management or referencing of user attributes through the database, row-level security policies and attribute-based encryption policies can share the same attribute source. Since user attributes such as user roles, departments, tenants, and regions can simultaneously serve row-level filtering and column-level decryption judgment, business systems do not need to maintain two separate sets of unrelated attribute systems for row-level permissions and encryption authorization. Furthermore, because attribute-based encryption policies can also combine data row attributes to express decryption conditions, sensitive column access control can more closely align with actual business authorization relationships. This reduces the security risks associated with redundant attribute maintenance, redundant policy configuration, and asynchronous authorization states.

[0049] In one possible implementation, the encrypted storage of the plaintext of the sensitive column includes: Generate or obtain data encryption keys for sensitive columns in the first data row; The plaintext of the sensitive column in the first data row is encrypted using the data encryption key to obtain the ciphertext of the sensitive column; Based on the attribute-based encryption strategy bound to the sensitive column and the system parameters, the data encryption key is encapsulated using attribute-based encryption to obtain the key ciphertext; The system stores the ciphertext of the sensitive column, the ciphertext of the key, the policy identifier of the attribute-based encryption policy, and encryption metadata.

[0050] Figure 5 This illustrates the process of inserting data into a table containing attribute-based encrypted columns. When a user inserts ordinary or sensitive fields, the database identifies the sensitive column (also known as an attribute-based encrypted column) and generates or obtains a data encryption key (DEK) for that column. For example, when a user executes an INSERT or UPDATE statement, the database parses the target table's structure metadata and finds that certain columns have data types defined as "attribute-based encrypted types" (such as ABE_TEXT, ABE_NUM, etc.), indicating that these columns cannot directly store plaintext and require encryption. After confirming that the column is an encrypted column, the database immediately prepares a data encryption key for subsequent symmetric encryption of the plaintext in that column. This can be achieved by calling a cryptographically secure random number generator (CSPRNG) to create a completely new and unique DEK, or by reusing an existing DEK from an existing key pool, cache, or the same row.

[0051] The database uses the aforementioned data encryption key to encrypt the plaintext of the sensitive column, obtaining the ciphertext of the sensitive column data. Subsequently, the database encapsulates the data encryption key using attribute-based encryption according to the attribute-based encryption policy bound to the column and system parameters. Finally, the database saves the ciphertext data, the encapsulated data encryption key, and necessary policy and encryption metadata.

[0052] Taking the INSERT operation as an example, when a user executes INSERT INTO employee (id, name, salary, dept, level) VALUES (1, 'Zhang San', 15000, 'Finance Department', 'L2'), the database first checks the metadata of the employee table, and identifies that the salary column is of the ABE_NUM type (attribute-based encryption column); then it invokes a cryptographically secure random number generator to generate a 256-bit random byte string as the Data Encryption Key (DEK); next, it uses the DEK to perform AES-256-GCM symmetric encryption on the plaintext value 15000 to obtain the data ciphertext 0x7F2A...; then it uses the system public parameter (PK), the row attributes of the current row (dept=Finance Department, level=L2) and the attribute-based encryption policy (such as P1001) bound to this column to perform CP-ABE encapsulation on the DEK, so as to generate the key ciphertext 0xB3E1...; finally, the data ciphertext, the key ciphertext, the policy identifier and the encryption metadata are packaged into a composite structure, which is stored in the actual storage location of the salary field.

[0053] Through this process, the sensitive columns stored in the database are no longer plaintext values, but ciphertext data protected by the attribute-based encryption policy. Even if a subsequent user can access this data row, the user still needs to satisfy the corresponding attribute-based encryption policy to obtain the plaintext of the sensitive column.

[0054] Step 102: In response to an access request for the database from a current accessing user, execute a row-level security policy to determine a second data row visible to the current accessing user.

[0055] Step 103: Identify the attribute-based encryption column in the second data row.

[0056] In practical applications, the database may locate the target table or column that the current accessing user requests to access, then look up the system catalog or the sensitive column binding table, and judge column by column whether there is an ABE type and a policy identifier; if there is a mark, the column is determined as an attribute-based encryption column.

[0057] Step 104: Acquire the user private key of the current accessing user, and use the user private key to decrypt the encapsulated data encryption key in the attribute-based encryption column.

[0058] Step 105: If the decryption succeeds, use the data encryption key to decrypt the sensitive column ciphertext in the attribute-based encryption column, obtain the sensitive column plaintext, and return the sensitive column plaintext to the current accessing user.

[0059] In a possible implementation, the executing the row-level security policy includes: Based on the user attributes of the current user, apply the filtering conditions in the row-level security policy to each row of the data table requested by the current user. The second data row that meets the filtering conditions is retained.

[0060] Figure 6 This illustrates the execution process of a row-level security policy. When creating a row-level security policy, the database can use user attributes managed by the database as part of the row filtering conditions. Row-level security policies are general rules bound to tables, achieving personalized filtering by referencing user attributes through expressions, rather than creating a separate policy for each user. When querying, updating, or deleting data, the database first performs a row-level security check based on the attribute information corresponding to the current user. Data rows that meet the row-level policy proceed to the next processing step; data rows that do not meet the row-level policy are filtered or denied access.

[0061] In this process, row-level security policies still address the question of "whether the current user can access the row." Attribute-based encryption policies further address the question of "whether the current user can decrypt sensitive columns in the row." Although they control different objects, they can share the same set of user attribute sources, thus forming a collaborative relationship between row-level access control and column-level ciphertext protection.

[0062] In one possible implementation, if decryption fails, according to a preset decryption failure handling strategy, one of the following operations is performed: returning a de-identified value to the user, returning an empty value to the user, or returning an error message to the user.

[0063] Figure 7 This illustrates the process of querying data containing attribute-based encrypted columns. Upon receiving the query request, the database first executes a row-level security policy, retaining only the data rows visible to the current user. This reduces administrative complexity while maintaining flexibility in access control.

[0064] For the remaining data rows, the database further identifies the attribute-based encryption columns and attempts to decrypt the data encryption key encapsulated by the attribute-based encryption policy using the current user's private key. If the user attributes satisfy the corresponding policy, the data encryption key can be decrypted. The database then uses this key to decrypt the ciphertext of sensitive columns and returns the plaintext result to the user.

[0065] If the current user cannot decrypt the data encryption key, it means that although the user may have row-level visibility permissions, they do not meet the column-level decryption conditions for sensitive columns. In this case, the database can return a masked value, a null value, or an error message according to the policy configuration. The design principle for masked values ​​is to expose only the minimum information required by the business and never expose the original plaintext. For example, it can be a fixed mask, with a mobile phone number displayed as 1. 1. The amount is displayed as .

[0066] The specific return method can be determined by the parameters when the policy is created, the database configuration, or business security requirements.

[0067] This query process reflects the core access control sequence: first, determine if the data row is visible, then determine if the sensitive columns in the visible row can be decrypted. Through this sequence, the database can simultaneously support row-level filtering and column-level ciphertext protection.

[0068] Because sensitive fields can be used as attribute-based encrypted columns in table structure definitions, the database can automatically encrypt sensitive data, encapsulate encryption keys, and maintain encrypted metadata during insertion and updates. During queries, the database can automatically attempt key decryption and ciphertext decryption after row-level security filtering, eliminating the need for application systems to repeatedly write encryption / decryption, data masking, and permission checks in every query chain. Therefore, compared to application-side field encryption, external encryption services, or ordinary database encryption functions, the above method reduces the invasiveness of business code and improves the consistency of sensitive data protection logic.

[0069] In one possible implementation, the method further includes: In response to receiving an update request from a third user for a third data row, determine whether the third user has permission to access or update the third data row based on the row-level security policy; If the row-level security policy is satisfied and the updated content of the third data row contains a sensitive column, the plaintext of the new sensitive column is encrypted, and the data encryption key corresponding to the third data row is re-encapsulated according to the attribute-based encryption policy bound to the sensitive column. If the updated content of the third data row does not contain sensitive columns and affects the data row attributes on which the attribute base encryption policy depends, the data encryption key or ciphertext metadata corresponding to the third data row is re-encapsulated according to the policy association relationship so that the decryption control of the sensitive columns is consistent with the changes in data row attributes.

[0070] Figure 8This illustrates the process of updating data in an attribute-based encrypted column. Upon receiving an update request, the database first determines whether the current user has permission to access or update the target row based on the row-level security policy. If the row-level security policy is not met, the update operation is rejected or filtered. If the row-level policy is met, the database continues processing the field to be updated.

[0071] When the update includes attribute-based encryption columns, the database encrypts the plaintext of the new sensitive columns and updates the corresponding data encryption key encapsulation according to the attribute-based encryption policy bound to that column. When the update does not directly include attribute-based encryption columns but affects the data row attributes upon which the attribute-based encryption policy depends, the database can also reprocess the relevant key encapsulation or ciphertext metadata based on the policy association. This ensures that the decryption control of sensitive columns remains consistent with changes in data row attributes.

[0072] In practice, data encryption keys can be regenerated or reused provided that security policies are met; the specific method can be determined based on performance, security level, and data management requirements. It should be noted that this application does not limit specific key reuse strategies, but emphasizes that the database should maintain consistency between the ciphertext state of sensitive columns and the attribute-based encryption strategy during the update process.

[0073] In one possible implementation, the method further includes: In response to receiving a deletion request from a fourth user for a fourth data row, determine whether the fourth user has permission to delete the fourth data row based on the row-level security policy; If the row-level security conditions are not met, the deletion is rejected or filtered, and the information on whether the fourth data row exists is not returned to the fourth user. If the row-level security conditions are met, delete all content of the fourth data row.

[0074] Figure 9 This illustrates the process of deleting data containing attribute-based encrypted columns. Upon receiving a deletion request, the database first determines whether the current fourth user is authorized to delete the fourth data row based on row-level security policies. If the current user does not meet the row-level security requirements, the database rejects or filters the deletion operation. If the current user meets the row-level security requirements, the database deletes the row data and its associated ciphertext content, namely, the ordinary column data, sensitive column ciphertext, the encryption key for the data encapsulated in attribute-based encryption, and encrypted metadata in the fourth data row.

[0075] The core control point for deletion operations is row-level permission verification. In other words, deleting a row of data does not require the current user to be able to decrypt all sensitive columns in that row. This is because the deletion action focuses on whether the user has the permission to operate on that data row, rather than whether the user can read the plaintext of sensitive columns. This approach maintains consistency between deletion semantics and row-level security policies.

[0076] In enterprise data management, e-government, financial systems, multi-tenant platforms, and domestic substitution scenarios, the above methods can improve the cost-effectiveness of security capability implementation. Because row-level security, user attributes, attribute-based encryption policies, and sensitive column processing logic can be uniformly configured and executed on the database side, business systems do not need to adapt to multiple permission and encryption models separately. Furthermore, because access control results can take effect collaboratively in database query, insert, update, and delete processes, subsequent auditing, troubleshooting, and permission verification are easier to standardize. Therefore, compared to solutions that separate row-level security from application-side encryption, the above methods reduce system integration complexity, lower application transformation costs, and improve the consistency and maintainability of sensitive data access control in the database.

[0077] Figure 10 This illustrates the process of issuing and using user private keys. The database constructs a user attribute set based on the attribute fields and their values ​​in the user attribute table, and submits this attribute set to an external authorization center when key issuance is required. The external authorization center generates a user private key based on its stored master key and the user attribute set. When a user subsequently accesses attribute-based encrypted columns in the database, the database attempts to decrypt the data encryption key using the private key corresponding to the current user during the access process.

[0078] In the above process, the external authorization center is responsible for master key safekeeping and user private key generation, while the database is responsible for user attribute management, policy management, and access process coordination. This avoids the database directly holding the master key while simultaneously integrating database access control with attribute-based encryption capabilities. Because the master key is not directly stored by the database, database-side leakage or misoperation will not directly expose the attribute-based encryption master key. Since the database still holds the public parameters required for encryption and policy binding and can participate in the key distribution process based on user attribute sets, database access control capabilities and external authorization capabilities can collaborate effectively. Therefore, it enhances the protection capabilities of sensitive columns on the database side while avoiding concentrating all key management responsibility within the database.

[0079] In this embodiment, row-level security and attribute-based encryption are integrated into the database access control process. Based on a preset attribute-based encryption strategy, row attributes, and system parameters, the plaintext of sensitive columns in the first data row is encrypted and stored. Furthermore, because the database first performs row-level filtering and then performs attribute-based decryption control on sensitive columns in visible rows, even if a user can access a data row, they may not necessarily obtain the plaintext of the sensitive fields in that row, thus achieving controlled decryption of the encrypted sensitive columns. In this way, the above method solves the problem in the prior art where row-level visibility and column-level decryptability cannot be executed in a coordinated manner, providing finer-grained data access control capabilities on the database side while ensuring database storage security and good database performance.

[0080] Figure 11 The diagram illustrates the overall principle of the database access control method described above. An external authorization center is responsible for generating system parameters and a master key, with the master key stored by the external authorization center; the database only registers the system parameters. The database maintains user attributes that can be used for access control and forms a unified attribute source based on these user attributes. Row-level security policies use these user attributes to determine which data rows the current user can access; attribute-based encryption policies use user attributes and necessary data row attributes to determine whether the current user can decrypt sensitive columns. Thus, the database simultaneously completes row-level visibility control and column-level decryptability control within a single access process.

[0081] This application also provides a database access control device, the device comprising: The authorization center interaction module is used to receive system parameters generated by the external authorization center and submit user attribute sets to the external authorization center during the key issuance process; The user attribute management module is used to manage user attributes that can be identified on the database side, and supports writing, updating and querying user attributes; The attribute tagging module is used to identify attribute fields in the user attribute table that can be used for access control; The attribute set construction module is used to construct a set of user attributes for attribute-based encryption authorization based on user attribute fields and their data content. The row-level security policy module is used to enforce row-level access control based on user attributes managed by the database. The attribute-based encryption policy module is used to create, save, and parse attribute-based encryption access policies for sensitive columns; The attribute-based encryption column management module is used to provide attribute-based encryption types and maintain the binding relationship between encryption columns and encryption policies; The encrypted data processing module is used to complete data encryption key generation, sensitive data encryption, key encapsulation, key decapsulation, and plaintext recovery during the insertion, update, and query processes. The query result processing module is used to return de-identified values, null values, or error messages according to a strategy when the user does not meet the column-level decryption conditions.

[0082] To further illustrate the implementation and technical effects of the above method in actual business scenarios, the following explanation uses a construction enterprise engineering contract management system as an example. An attribute-based encryption authorization center, composed of cryptographic machines, is deployed externally to the system. This center is responsible for generating and storing the attribute-based encryption master key and generating corresponding user private keys based on user attributes. User information, such as project managers, engineering technicians, procurement personnel, cost estimators, and financial personnel, is stored in a user attribute table in the database, including attributes such as project affiliation, department, job role, and business permissions.

[0083] As a business entity within the system, engineering contracts have their related information stored in the same contract data table, with each row corresponding to one engineering contract. Contract records include fields such as contract number, contract name, counterparty, project, project scope, technical requirements, contract amount, unit price, payment terms, amount already paid, settlement amount, and receiving account. The database first controls which contract records different users can access through row-level security policies. For example, project managers can access contracts under their assigned projects, engineering technicians can access contracts within their assigned projects or professional scope, and cost estimators and finance personnel can access contracts related to their settlement or payment responsibilities. Even for the same contract with access granted, the visibility of fields varies between different roles. For instance, engineering technicians can view project scope and technical requirements but not the contract unit price, settlement amount, or receiving account; cost estimators can view the contract amount, unit price, and settlement amount but not financial account information unrelated to their work; and finance personnel can view payment terms, amount already paid, and receiving account information.

[0084] For sensitive fields requiring differentiated protection, the database sets them as attribute-based encrypted columns and configures corresponding access policies based on job roles and business permissions. When a user queries contract data, the database first executes row-level security policies to determine if the user can access the contract record, and then determines whether the user has decryption permissions for the corresponding sensitive fields based on user attributes. Thus, on the same project contract entity, row-level security controls which contract records a user can access, while attribute-based encryption further controls which sensitive fields in the same contract record a user can read, thereby achieving coordinated control of row-level visibility and column-level decryptability.

[0085] The above are embodiments of the method proposed in this application. Based on the same inventive concept, embodiments of this application also provide a device, the structure of which is as follows: Figure 12 As shown.

[0086] Figure 12This is a schematic diagram of the internal structure of a device provided in an embodiment of this application. Figure 12 As shown, the device includes: At least one processor 1201; And a memory 1202 that is communicatively connected to at least one processor; The memory 1202 stores instructions that can be executed by at least one processor. The instructions are executed by at least one processor 1201 to enable at least one processor 1201 to execute the database access control method described above.

[0087] Some embodiments of this application provide corresponding to Figure 1 A non-volatile computer storage medium stores computer-executable instructions, which are configured to execute the aforementioned database access control method.

[0088] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for IoT devices and media are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0089] The systems, media, and methods provided in this application are one-to-one correspondences. Therefore, the systems and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the systems and media will not be repeated here.

[0090] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0091] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0092] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0093] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0094] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0095] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0096] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0097] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0098] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A database access control method, characterized in that, The method is executed by a database, and the method includes: In response to a data write request to write a first data row to the database, the row attribute of the first data row is determined, and the plaintext of the sensitive columns in the first data row is encrypted and stored according to a preset attribute-based encryption strategy, the row attribute, and system parameters. The system parameters are generated by an external authorization center and registered to the database. In response to the current user's access request to the database, a row-level security policy is executed to determine the second data row that is visible to the current user; Identify the attribute-based encryption column in the second data row; Obtain the user's private key of the currently accessing user, and use the user's private key to decrypt the data encryption key encapsulated in the attribute base encryption column; If decryption is successful, the ciphertext of the sensitive column in the attribute base encryption column is decrypted using the data encryption key to obtain the plaintext of the sensitive column, and the plaintext of the sensitive column is returned to the current accessing user.

2. The method according to claim 1, characterized in that, The method further includes: Once the database has been initialized and the system parameters have been registered, a user attribute table is created or accessed, and fields that can be used as access control attributes are identified by attribute tagging. Create an attribute-based encryption policy, wherein the attribute-based encryption policy is bound to a specified business table or column.

3. The method according to claim 2, characterized in that, When the user attributes of the first user in the external business system are inserted or updated, the user attributes of the first user in the user attribute table are updated synchronously, and the attribute set of the first user is constructed according to the fields marked as access control attributes in the user attributes of the first user and their field values. The attribute set of the first user is used for the row-level security policy determination of the first user and is submitted to the external authorization center. The external authorization center generates the user private key of the first user based on the master key stored in the external authorization center and the attribute set of the first user.

4. The method according to claim 1, characterized in that, The method further includes: In response to the second user's business table creation request, the target field is defined as an attribute-based encryption column according to the attribute-based encryption type specified in the business table creation request, and the target field is bound to the attribute-based encryption policy corresponding to the created policy identifier according to the policy identifier specified in the business table creation request.

5. The method according to claim 1, characterized in that, The step of encrypting and storing the plaintext of sensitive columns in the first data row includes: Generate or obtain data encryption keys for sensitive columns in the first data row; The plaintext of the sensitive column in the first data row is encrypted using the data encryption key to obtain the ciphertext of the sensitive column; Based on the attribute-based encryption strategy bound to the sensitive column and the system parameters, the data encryption key is encapsulated using attribute-based encryption to obtain the key ciphertext. The system stores the ciphertext of the sensitive column, the ciphertext of the key, the policy identifier of the attribute-based encryption policy, and encryption metadata.

6. The method according to claim 1, characterized in that, The execution of the row-level security policy includes: Based on the user attributes of the current user, apply the filtering conditions in the row-level security policy to each row of the data table requested by the current user. The second data row that meets the filtering conditions is retained.

7. The method according to claim 1, characterized in that, The method further includes: In response to receiving an update request from a third user for a third data row, determine whether the third user has permission to access or update the third data row based on the row-level security policy; If the row-level security policy is satisfied and the updated content of the third data row contains a sensitive column, the plaintext of the new sensitive column is encrypted, and the data encryption key corresponding to the third data row is re-encapsulated according to the attribute-based encryption policy bound to the sensitive column. If the updated content of the third data row does not contain sensitive columns and affects the data row attributes on which the attribute base encryption policy depends, the data encryption key or ciphertext metadata corresponding to the third data row is re-encapsulated according to the policy association relationship so that the decryption control of the sensitive columns is consistent with the changes in the data row attributes.

8. The method according to claim 1, characterized in that, The method further includes: In response to receiving a deletion request from a fourth user for a fourth data row, determine whether the fourth user has permission to delete the fourth data row based on the row-level security policy; If the row-level security conditions are not met, the deletion is rejected or filtered, and the information on whether the fourth data row exists is not returned to the fourth user. If the row-level security conditions are met, delete all content of the fourth data row.

9. A database access control device, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform a database access control method as described in any one of claims 1-8.

10. A computer storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, they implement a database access control method as described in any one of claims 1-8.

Images