Logical log visibility control in enclave database

Abstract

The invention relates to logical log visibility control in an enclave database. A database management system (DBMS) in an enclave for a data privacy protection database is provided. The system comprises a system directory table, a logic log and a DBMS engine. The engine is configured to parse the logical log based on a request to retrieve the logical log to detect at least one predetermined identifier, and to distribute the logical log. The engine is further configured to, for each predetermined identifier detected in the logical log, determine an access control for the request with respect to a field in the data privacy protection database corresponding to a record in the system directory table, and retrieve secret data corresponding to the field when the access control indicates a first access control state, or when the access control indicates a second access control state, the secret data corresponding to the field is masked.

Description

Technical Field

[0001] The embodiments described herein generally relate to data privacy control of databases. More specifically, the embodiments described herein relate to fine-grained data privacy control of a data privacy protected database by a database management system (DBMS) in an enclave. Background Art

[0002] Compared with software-oriented encrypted database (S-EDB) systems, conventional hardware-enabled encrypted database (H-EDB) systems support more operations (e.g., database operations using Structured Query Language (SQL), etc.), but still far fewer than general-purpose database systems (e.g., SQL database systems, etc.). Conventional H-EDB systems typically have a partial hardware encryption (P-HE) architecture that uses a remote attestation (RA) mechanism to share client-side private keys and register authenticated DBMS operator code within an enclave. Once ciphertext (e.g., via a DBMS, etc.) from one end (e.g., the user side, etc.) is transmitted to the enclave, the enclave first decrypts the ciphertext into plaintext, performs computations or operations on the plaintext, then encrypts the computed plaintext (if necessary), and then replies to the DBMS.

[0003] Generally, the design of P-HE databases is based on enclave constraints, such as the constraints of Trusted Execution Environment (TEE) memory limitations or restrictions. Therefore, it may be impractical to authenticate the entire DBMS into the enclave to implement a full hardware encryption (F-HE) database system for runtime execution, and the input / output (I / O) costs in the P-HE database between the enclave and the DBMS may seriously affect system performance. Summary of the Invention

[0004] Recently emerged increased TEE memory enables the creation of an F-HE architecture. The features in the embodiments disclosed herein can provide and otherwise implement an "in-enclave" (i.e., F-HE) database system (e.g., a relational database system, etc.) to support data privacy protection and verifiable functions by residenting the entire DBMS (or the entire database system) into the TEE (e.g., TEE memory, etc.), thereby reforming the current P-HE model.

[0005] It should be understood that in the F-HE database architecture, this mechanism can provide security and / or privacy protection by preventing data leakage from all memory, (multiple) processors (such as a central processing unit (CPU)), and I / O. In this way, data structures and data stores that do not have an explicit retrieval interface and are used internally by the DBMS (e.g., system and physical logs) can be prevented from being viewed by adversaries. For example, the redo log of a database system (which is a physical log) stores all changes made to the database in a log file. Therefore, operations involving the redo log can include loading the redo log into memory and participating in processor (e.g., CPU, etc.) calculations, writing and reading the log file by disk I / O, and transmitting between replicas via network I / O. In the F-HE paradigm, operations related to the redo log do not leak data because enclave memory and the CPU are protected to ensure security and privacy; further, the data may have been encrypted by the enclave or TEE before being written to disk, and network transmission can be protected by, for example, the remote attestation - transport layer security (RA-TLS) protocol.

[0006] It should also be understood that in the F-HE database architecture, for data structures and data stores with some explicit retrieval interfaces (e.g., logical logs, etc.), additional security and / or privacy protection measures are required. The features in the embodiments disclosed herein can provide logical log encoding and enabled mask visibility control to implement an efficient privacy-protected database logical log in F-HE, thereby reforming client-side cryptography in conventional P-HE databases (e.g., using RA mechanisms, etc.). That is, the features in the embodiments disclosed herein can achieve security and / or privacy protection without the need for client-side cryptography and the corresponding processes related to client-side cryptography.

[0007] In one example embodiment, a database management system (DBMS) in an enclave for a data privacy-protected database is provided. The system includes a system catalog table, a logical log, and a DBMS engine, which is configured to parse the logical log based on a request for retrieving the logical log to detect at least one predetermined identifier. The engine is further configured to: for each predetermined identifier detected in the logical log, determine access control for the request regarding the fields corresponding to the records in the system catalog table in the data privacy-protected database; and when the access control indicates a first access control state, retrieve the secret data corresponding to the field, or when the access control indicates a second access control state, mask the secret data corresponding to the field. The engine is further configured to distribute the logical log with the retrieved or masked secret data based on the request.

[0008] In another example embodiment, a method for data privacy control of a data privacy protection database is provided. The method includes: parsing, by a database management system (DBMS) in an enclave, a logical log based on a request for retrieving the logical log to detect at least one predetermined identifier. The method further includes: for each predetermined identifier detected in the logical log, determining access control for the request with respect to a field in the data privacy protection database corresponding to a record in a system catalog table; and retrieving secret data corresponding to the field when the access control indicates a first access control state, or masking the secret data corresponding to the field when the access control indicates a second access control state. The method further includes distributing the logical log with the retrieved or masked secret data based on the request.

[0009] In yet another example embodiment, a non-transitory computer-readable medium storing computer-executable instructions is provided. The instructions, when executed, cause one or more processors to perform operations including: parsing, by a database management system (DBMS) in an enclave, a logical log based on a request for retrieving the logical log to detect at least one predetermined identifier; for each predetermined identifier detected in the logical log: determining access control for the request with respect to a field in the data privacy protection database corresponding to a record in a system catalog table, retrieving secret data corresponding to the field when the access control indicates a first access control state, or masking the secret data corresponding to the field when the access control indicates a second access control state; and distributing the logical log with the retrieved or masked secret data based on the request. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The drawings illustrate various embodiments of the systems and methods of the present disclosure, as well as embodiments of various other aspects. Any ordinary person skilled in the art will understand that the element boundaries shown in the figures (e.g., boxes, multiple sets of boxes, or other shapes) represent an example of a boundary. In some examples, it may be possible that one element can be designed as multiple elements, or multiple elements can be designed as one element. In some examples, an element shown as an internal component of one element can be implemented as an external component of another element, and vice versa. The following figures are described in a non-limiting and non-exhaustive manner. The components in the figures are not necessarily drawn to scale, but emphasis is placed on illustrating the principles. In the following detailed description, the embodiments are described only by way of illustration, as various changes and modifications may be apparent to those skilled in the art from the following detailed description.

[0011] Figure 1 is a schematic view of an example data privacy protection database system arranged according to at least some of the embodiments described herein.

[0012] Figure 2 is a schematic view of the architecture of a database system according to at least some embodiments described herein.

[0013] Figure 3A is a schematic view of the logical log file of a data privacy protection database according to at least some embodiments described herein.

[0014] Figure 3B is a schematic view of the output logical log file of a data privacy protection database according to at least some embodiments described herein.

[0015] Figure 3C is a schematic view of another output logical log file of a data privacy protection database according to at least some embodiments described herein.

[0016] Figure 3D is a schematic view of yet another output logical log file of a data privacy protection database according to at least some embodiments described herein.

[0017] Figure 4 is a flowchart showing an example processing flow of a logical log visibility control algorithm for a data privacy protection database system in an enclave according to at least some embodiments described herein.

[0018] Figure 5 is a schematic structural diagram of an example computer system suitable for implementing an electronic device arranged according to at least some embodiments described herein. Detailed Description

[0019] In the following detailed description, specific embodiments of the present disclosure are described with reference to the accompanying drawings, which form a part of this specification. In this specification and the accompanying drawings, unless the context otherwise requires, the same reference numerals denote elements that can perform the same, similar, or equivalent functions. Furthermore, unless otherwise stated, the description of each subsequent drawing may refer to features from one or more of the previous drawings to provide a clearer context and a more substantial explanation for the current example embodiment. Nevertheless, the example embodiments described in the detailed description, the drawings, and the claims are not intended to be limiting. Other embodiments may be utilized and other changes may be made without departing from the spirit or scope of the subject matter presented herein. It will be readily understood that the various aspects of the present disclosure, as generally described and shown in the drawings herein, can be arranged, substituted, combined, separated, and designed in a wide variety of configurations, all of which are explicitly contemplated herein.

[0020] It should be understood that the disclosed embodiments are merely examples of the present disclosure, which can be embodied in various forms. Well-known functions or configurations are not described in detail to avoid obscuring the present disclosure with unnecessary details. Therefore, the specific structural and functional details disclosed herein should not be construed as restrictive, but merely as a basis for the claims and as a representative basis for teaching those skilled in the art to employ the present disclosure in various ways in almost any appropriate detailed structure.

[0021] Additionally, the present disclosure may be described herein in terms of functional block components and various processing steps. It should be understood that such functional blocks can be implemented by any number of hardware and / or software components configured to perform the specified functions.

[0022] The scope of the present disclosure should be determined by the appended claims and their legal equivalents, rather than by the examples given herein. For example, the steps recited in any method claim can be performed in any order, and are not limited to the order presented in the claims. Additionally, no element is essential to the practice of the present disclosure unless explicitly described herein as "critical" or "necessary".

[0023] As mentioned herein, "database" is a technical term, which can refer to an organized collection of data or a type of data storage that captures and analyzes data based on the use of a database management system (DBMS), software, applications, and / or the database itself that interacts with end-users. As mentioned herein, "database server" is a technical term, which can refer to a server that uses a database application and provides database services to other computer programs or computers, as defined by the client-server model. It should be understood that some DBMSs can typically provide database-server functionality, and some DBMSs may rely entirely on the client-server model for database access. It should also be understood that a DBMS can additionally provide the core facilities for managing a database; and the sum of the database, the DBMS, and the associated applications can be referred to as a database system. In an exemplary embodiment, the database system can be a relational database system, which can optionally use Structured Query Language (SQL) for database queries and updates. Further, it should be understood that a database can include one or more database tables, where each column of the database table represents a specific variable or field, and each row of the database table corresponds to a given record or entry. The table can list the values of each variable or field and / or the values of each record or entry.

[0024] As mentioned herein, "DBMS engine" or "database engine" is a technical term that can refer to the software or algorithms in a database system that identify and interpret database commands (e.g., SQL commands, etc.) to access the database and query the data in the database. In an example embodiment, the DBMS engine can include an SQL engine (or SQL query engine).

[0025] As mentioned herein, "enclave" is a technical term that can refer to a Trusted Execution Environment (TEE) that can protect sensitive data and code, e.g., from an attacker controlling, attempting to control, or otherwise compromising the operating system and hypervisor on a host machine. It should be understood that an enclave or TEE can refer to a protected set of system resources (e.g., memory, input / output, processor (such as a central processing unit), etc.) that operate within a common security domain and share a single common continuous security boundary. In an example embodiment, an enclave or TEE can refer to a private memory region designed to be protected from processes running at a higher privilege level. It should also be understood that an enclave or TEE can refer to a secure area for helping to protect the confidentiality and integrity of the code and data loaded therein. Data integrity prevents unauthorized entities outside the enclave or TEE from changing the data, while code integrity prevents the code in the enclave or TEE from being replaced or modified by unauthorized entities (which may include the computer owner or operator themselves). This can be done by implementing confidential architecture security that provides hardware-based memory encryption to isolate specific application code and data in memory. An enclave or TEE can be an isolated execution environment that provides security features such as isolated execution, the integrity of the applications executed in the enclave or TEE, and the confidentiality of its assets. That is, an enclave or TEE can provide an execution space that provides a higher security level for trusted applications running on the device than the operating system.

[0026] As mentioned herein, "fine-grained" or "granular" data privacy protection is a technical term that can refer to a method, procedure, or system for protecting data privacy for a particular part or aspect of the data. In an example embodiment, a fine-grained data privacy protection database can provide a fine-grained data privacy protection mechanism, e.g., to protect the data privacy of one or more columns / fields (and / or one or more rows / records) of a database table. In contrast, "coarse-grained" data privacy protection is a technical term that can refer to a method, procedure, or system for protecting data privacy to achieve generalized data privacy control. In an example embodiment, a coarse-grained data privacy protection database can provide a coarse-grained data privacy protection mechanism, e.g., to protect the data privacy of an entire database table (e.g., based on a user's role or permissions, etc.) rather than a particular part or aspect of the database table.

[0027] As mentioned herein, the "logical log" in a database is a technical term that may refer to a log file (e.g., a circular file, etc.) containing log records generated by, for example, a database server (e.g., a DBMS, etc.), for saving the history of transactions and database server changes since the last storage space backup. The log records in the logical log represent the logical operations of the database server, rather than the physical operations. As mentioned herein, the "physical log" in a database is a technical term that may refer to a log file containing the content of each changed row / record. Generally, the logical log records include not the changed row / record entries, but the database commands (e.g., SQL statements, etc.) that cause the row / record changes (e.g., insert, update, and / or delete statements, etc.). The logical log may describe the changes in the form of record images or commands (e.g., SQL statements, etc.). The physical log records include the entries of the content of each changed row / record. The physical log may describe the changes in a way that is more oriented towards underlying data block operations. In an exemplary embodiment, the logical log may include an audit log, while the physical log may include a redo log. It should be understood that although the logical log is used as an example when describing the features of the embodiment, any other suitable file having similar characteristics to the logical log may be applicable.

[0028] As mentioned herein, the "system catalog" table in a database is a technical term that may refer to the table(s) and / or view(s) that describe the database structure. It should be understood that the system catalog table may refer to a data dictionary, which may contain everything that the database knows about itself.

[0029] As mentioned herein, the "structured data" in a database is a technical term that may refer to pre-formatted data, the format of which is predefined as rows / records and columns / fields and is usually stored as a table. It should be understood that the structured data can be classified as quantitative data and can be highly organized and easy to understand in machine language. The structured data can be easily input, searched, and / or manipulated using a DBMS. In an exemplary embodiment, database tables (e.g., system catalog tables, etc.) are structured data. As mentioned herein, the "unstructured data" in a database is a technical term that may refer to complex, qualitative, and / or unorganized data, which may not conform to any one specific standard (e.g., the unstructured data can be numeric, alphabetic, boolean, etc. or a mixture of some or all of them), and may not be stored in the database because the data strings may have mixed data types that cannot be placed into the rows / records or columns / fields of a table. In an exemplary embodiment, log files (e.g., physical logs, logical logs, etc.) are unstructured data.

[0030] Figure 1Schematic view of an example data privacy protection database system 100 arranged according to at least some embodiments described herein.

[0031] System 100 may include terminal devices 110, 120, 130, and 140, network 160, and / or server 150. It should be understood that server 150 may be a database server that provides database services to other computer programs or to a computer, as defined by the client-server model. Terminal devices 110, 120, 130, and 140 may be (multiple) devices for querying (or operating, e.g., analyzing, processing, using, storing, sharing, accessing, etc.) a database on or from the server. It should also be understood that Figure 1 only an illustrative number of terminal devices, network, and server are shown. The embodiments described herein are not limited to the number of terminal devices, network, and / or server described. That is, the number of terminal devices, network, and / or server described herein is provided for descriptive purposes only and is not intended to be limiting.

[0032] According to at least some example embodiments, terminal devices 110, 120, 130, and 140 may be various electronic devices. The various electronic devices may include, but are not limited to, mobile devices such as smartphones, tablet computers, e-book readers, laptop computers, etc., desktop computers, and / or any other suitable electronic devices.

[0033] According to at least some example embodiments, network 160 may be a medium for providing a communication link between terminal devices 110, 120, 130, 140 and server 150. Network 160 may be the Internet, a local area network (LAN), a wide area network (WAN), a local interconnect network (LIN), a cloud, etc. Network 160 may be implemented via various types of connections, such as wired communication links, wireless communication links, fiber optic cables, etc.

[0034] According to at least some example embodiments, server 150 may be a server for providing various services to a user using one or more of terminal devices 110, 120, 130, and 140. Server 150 may be implemented by a distributed server cluster including multiple servers, or may be implemented by a single server.

[0035] A user may interact with server 150 via network 160 using one or more of terminal devices 110, 120, 130, and 140. Various applications or their localized interfaces, such as database applications, social media applications, online shopping applications, etc., may be installed on terminal devices 110, 120, 130, and 140.

[0036] It should be understood that the software applications or services according to the embodiments described herein and / or according to the services provided by the service provider can be executed by the server 150 and / or the terminal devices 110, 120, 130, and 140 (which may be referred to herein as user devices). Accordingly, the apparatus for the software applications and / or services can be arranged in the server 150 and / or the terminal devices 110, 120, 130, and 140.

[0037] It should also be understood that when the service is not remotely executed, the system 100 can optionally include the network 160 while including the terminal devices 110, 120, 130, and 140 or the server 150.

[0038] It should be further understood that the terminal devices 110, 120, 130, and 140 and the server 150 can each include one or more processors, memories, and storage devices storing one or more programs. Each of the terminal devices 110, 120, 130, and 140 and / or the server 150 can also each include an Ethernet connector, a Wi-Fi receiver, etc. The one or more programs, when executed by the one or more processors, can cause the one or more processors to execute the (multiple) methods described in any of the embodiments described herein. In addition, it should be understood that a non-volatile computer-readable medium can be provided according to the embodiments described herein. The computer-readable medium stores a computer program. The computer program is for executing the (multiple) methods described in any of the embodiments described herein when executed by a processor.

[0039] Figure 2 is a schematic view of the architecture of the database system 200 according to at least some of the embodiments described herein. It should be understood that unless otherwise specified, the processes disclosed herein can be performed by one or more processors (e.g., Figure 1 one or more processors of the terminal devices 110, 120, 130, and 140, Figure 1 the processor of the server 150, Figure 5 the central processing unit 505, and / or any other suitable processor).

[0040] As Figure 2As shown in FIG. 0, the database system 200 includes a DBMS 210. In an example embodiment, the DBMS 210 may reside entirely within the enclave 220. The enclave 220 may be a trusted execution environment (TEE), which may be a set of encrypted system resources (e.g., memory, input / output, processors (such as central processing units, etc.)). The DBMS 210 may include a DBMS engine 230. In an example embodiment, the DBMS engine 230 may be an SQL engine. The DBMS engine 230 may be designed, programmed, or otherwise configured to receive database commands (e.g., SQL statements, etc.) from the user 270 via the (multiple) applications 260, to generate / create or operate / access / manipulate one or more database tables 290, and / or to communicate with or control one or more tools or processes (such as the log manager 280).

[0041] In an example embodiment, one or more database tables 290 may be loaded into the enclave 220 by the DBMS 210, for example, via an encrypted channel 245 (e.g., a trusted execution environment-input / output transport layer security (TEE-IO TLS) channel, etc.) from a storage device 240. In an example embodiment, one or more database tables 290 may be saved from, stored in, or sent to the storage device 240 by the DBMS 210 via the encrypted channel 245 from the enclave 220.

[0042] In an example embodiment, the application 260 may execute on a device corresponding to or operated by the user 270 (such as Figure 1 the terminal devices 110, 120, 130, and 140), and / or Figure 1 the server 150. The user 270 may be the owner or operator of the database, a database administrator (DBA), an authorized user with the right to access and / or modify the database of the database system 200, etc. The device corresponding to the user 270 may run the application 260 or instruct the execution of the application 260 by, for example, providing input 272 to the application 260 and / or receiving output 272 from the application 260. The application 260 may communicate with the DBMS engine 230 via, for example, a secure network connection 265. The application 260 may be a fine-grained privacy protection application, a tamper-proof application, or any other suitable (multiple) application.

[0043] In an example embodiment, a device corresponding to a user (not shown) (such as Figure 1 the terminal devices 110, 120, 130, and 140) and / or Figure 1The server 150 can run or execute the application 250. The user can be the owner of the database, a database administrator (DBA), an authorized user having access to and / or modifying the database of the database system 200, etc. The application 250 can communicate with the DBMS 210 (and / or the DMBS engine 230) via, for example, the (multiple) secure network connections 255. The application 250 can be a coarse-grained privacy protection application or any other suitable (multiple) application.

[0044] In an example embodiment, one or more database tables 290 can include system tables (such as the (multiple) system catalog tables), user-defined / generated tables, or any other suitable database tables, views, etc. One or more database tables 290 can be the (multiple) database tables of a privacy protection database (e.g., a fine-grained privacy protection database, etc.).

[0045] For example, the user 270 can be a human resources staff. On the corresponding device, the user 270 can create or generate a payroll table (or database DB, not shown), which has columns / fields such as employee names, employee salaries, etc. The creation or generation of the payroll table can be performed via the interface 272 between the application 260 and the user 270, which sends the corresponding database commands to the DBMS engine 230 for execution (i.e., for creating or generating the payroll table). That is, the user 270 can be the owner of the payroll table. When creating or generating the payroll table or afterwards, the user 270 can send the database command 275 (e.g., creating the payroll table and / or selecting or specifying one or more fields (such as the employee salary field, etc.)) as the (multiple) secret or private columns / fields), so that the DBMS engine 230 can create or update the system catalog table 290. That is, the payroll table is considered a fine-grained privacy protection table / database because a part of the table / database (such as the employee salary field, etc.) is protected, i.e., any user (including the root user or DBA of the DBMS 210, etc.) cannot view or access this part except the owner 270 (and / or the viewer to whom the owner 270 grants the clear-text viewing permission for the (multiple) secret / private fields).

[0046] It should be understood that the database command 275 is sent via the interface 272 of the application program 260, and this interface sends the corresponding database command 275 to the DBMS engine 230 for execution, that is, for creating or updating the system catalog table to add records / rows and / or (1) inserting the unique identifier (e.g., UID1) of the secret column / field (e.g., the employee salary field) of the salary table into the column identifier (e.g., column ID (Col-ID)) field or updating it, (2) inserting the user identifier (e.g., user 1) of the owner / creator of the salary table into the table / database owner (e.g., owner (Owner)) field or updating it, and / or (3) inserting the secret or private setting (e.g., high) of the UID1 of the salary table into the secret level (e.g., secret level (Sec-Level)) field or updating it. It should also be understood that when the secret level field is set or updated to "high" (or a similar level), no user (including the root user or DBA of the DBMS 210, etc.) can see or otherwise access the corresponding secret column / field (i.e., the employee salary field of the salary table, etc.) except for the owner "user 1" of the corresponding table / database (and / or the viewer(s) to whom the owner has granted the clear text viewing permission for the secret / private field(s)). When the secret level field is set or updated to "medium" (or a similar level), some characteristics of the corresponding secret column / field (e.g., some summaries of the employee salary, etc.) can be seen or otherwise accessed by users other than the owner and the viewer(s), subject to other existing rules regarding the permissions of the user(s). When the secret level field is set or updated to "low" (or a similar level), more characteristics of the corresponding secret column / field (compared to the "medium" level) (e.g., some summaries of the employee salary, etc.) can be seen or otherwise accessed by users other than the owner and the viewer(s), subject to other existing rules regarding the permissions of the user(s). In the example embodiment, depending on the configuration or definition of the level(s), "high", "medium", and "low" can be numerical values arranged in ascending or descending order. In another embodiment, the secret level (e.g., Sec-Level) field can be optional.

[0047] It should be further understood that the device corresponding to user 270 can also send database commands (not shown) via interface 272 of application 260, and this interface sends the corresponding database commands to DBMS engine 230 for execution, that is, for creating or updating the system catalog table to add records / rows and / or (1) add the viewer(s) of the secret column / field (e.g., the employee salary field) of the salary table to the viewer list (e.g., the Viewer field) or update it. In the example embodiment, regardless of the value of the "secret level" field, the secret column / field (e.g., the employee salary field of the salary table, etc.) can be seen by the owner (e.g., user 1) and the viewer(s) listed in the "Viewer" field.

[0048] It should also be understood that the secret / private field(s) visible to the user can indicate that the user can view the clear text of the value / data of the secret / private field. The secret / private field(s) not visible (or invisible) to the user can indicate that the user cannot view the clear text of the value / data of the secret / private field, cannot view the secret / private field at all, and / or can view the masked data of the secret / private field. In the example embodiment, the masked data can indicate that the data is encoded, encrypted into cipher text, masked by adding random value(s), and / or otherwise prevent viewing of the clear text of the data.

[0049] In the example embodiment, DBMS engine 230 can include a log manager 280. In another example embodiment, DBMS engine 230 can be independent of log manager 280, and can communicate with log manager 280, send commands to it, control and / or operate it. During the operation of DBMS 210, log manager 280 can enter (e.g., save, store, record, etc.) database commands (e.g., SQL statements, etc.) that cause row / record changes (e.g., insert, update, and / or delete statements, etc.) into the logical log (which can be generated, updated, parsed, and / or manipulated by log manager 280). It should be understood that all database commands (e.g., SQL statements, etc.) including the above commands (such as generating, accessing, updating, inserting, deleting, operating, manipulating, and / or processing secret / private column / field(s)) can be entered into the logical log unless otherwise explicitly described. That is, log manager 280 can enter data changes into the database for different data manipulation operations (e.g., delete, insert, update, etc.) performed on user-definable database objects (tables, columns / fields, etc.). It should also be understood that log manager 280 can generate, update, parse, manipulate, and / or process any other suitable log (e.g., system and / or physical log(s), etc.).

[0050] Figure 3A is a schematic view of a logical log file 300 of a data privacy protection database according to at least some embodiments described herein. Figure 3B is a schematic view of an output logical log file 301 of a data privacy protection database according to at least some embodiments described herein. Figure 3C is a schematic view of another output logical log file 302 of a data privacy protection database according to at least some embodiments described herein. Figure 3D is a schematic view of yet another output logical log file 303 of a data privacy protection database according to at least some embodiments described herein. It should be understood that the logical log files (300, 301, 302, 303) are provided for illustrative purposes only and are not intended to be restrictive. It should also be understood that the logical log files (300, 301, 302, 303) show the order or sequence of data and not necessarily the exact location of the data in the logical log file.

[0051] It should be understood that the logical log 300 (e.g., an audit log, etc.) can be configured or generated to record all changes made to a database (e.g., a fine-grained data privacy protection database). The logical log 300 can be created by a DBMS (e.g., a database server, a DBMS engine, and / or a log manager of the DBMS) and can contain a record of all database commands (e.g., SQL statements, etc.) that modify the data of the database. In an example embodiment, the logical log 300 can be used as an audit trail of changes and can be used for various purposes such as data recovery, replication, and / or database monitoring. Database commands (e.g., requests for retrieving the logical log) can be used to view the data or content stored in the logical log 300 in a human-friendly format. It should also be understood that the logical log 300 can be an unstructured file and there is a need unmet to locate the values of secret / private columns / fields in the logical log (which can be met by the features in the embodiments disclosed herein).

[0052] As Figure 2As described in the description, a logical log (e.g., 300) can be generated or updated during the operation of the DBMS 210. In an example embodiment, in the logical log 300, any data (e.g., SQL statements, etc.) can be shown in its original form, e.g., shown as plaintext data (310A, 310B, 310C, 310D, etc.), except for the secret / private data of the (multiple) secret / private columns / fields. In the logical log 300, for all the secret / private data of the (multiple) secret / private columns / fields, a corresponding secret column / field identifier (320A, 320B, 320C, 320D, etc.), a corresponding column / field identification (330A, 330B, 330C, 330D, etc.), and / or a corresponding length (340A, 340B, 340C, 340D, etc.) are inserted before the secret / private data of the (multiple) secret / private columns / fields (350A, 350B, 350C, 350D, etc.). It should be understood that the secret column / field identifier (320A, 320B, 320C, 320D, etc.) can be a predefined or predetermined constant (the same for all (multiple) secret column / field identifiers), e.g., a 256-bit (or 32-byte) constant, which can be used as an identifier for the data of the secret / private column / field. It should also be understood that the value of the secret column / field identifier (320A, 320B, 320C, 320D, etc.) can be unique in the logical log and can be different from the (multiple) values of all other data / content in the logical log. Further, it should be understood that the size of the column / field identification (330A, 330B, 330C, 330D, etc.) can be predefined or predetermined (e.g., 16 bytes, etc.), and the value of the column / field identification (330A, 330B, 330C, 330D, etc.) can indicate the identification of the secret / private column / field. The size of the "length" (340A, 340B, 340C, 340D, etc.) can be predefined or predetermined (e.g., two bytes, etc.), and the value of the length (340A, 340B, 340C, 340D, etc.) can indicate the length of the secret / private data (350A, 350B, 350C, 350D, etc.) of the secret / private column / field.

[0053] In an example embodiment, when the user (e.g., Figure 2When a user 270 sends a request for retrieving the logical log 300 via a device, the device can send a database command (e.g., a logical log retrieval command, etc.) via the interface 272 of the application 260, and this interface sends the database command to the DBMS engine 230 (and / or the log manager 280 for execution), so that the output logical log (e.g., 301, 302, 303) can be returned to the user based on or in response to the request from the user (e.g., via the interface 272 of the application 260, which receives the corresponding result from the DBMS engine 230). It should be understood that the user device that issues / sends a request to the DBMS can be the owner and / or viewer of the database (e.g., a fine-grained privacy-protected table / database with (multiple) secret / private columns / fields) or any other (multiple) suitable users (e.g., those users who cannot see the (multiple) secret / private columns / fields). It should also be understood that the information of the user (e.g., the user's identification, etc.) can be included in the request to the DBMS.

[0054] In an example embodiment, when receiving and responding to a user's request for retrieving the logical log 300, the DBMS engine (e.g., Figure 2 230) and / or the log manager (e.g., Figure 2 280) can parse the logical log 300 to detect or search for predefined secret column / field identifiers (320A, 320B, 320C, 320D, etc.). When any secret column / field identifier (320A, 320B, 320C, 320D, etc.) is detected or located, the DBMS engine (and / or the log manager) can mark the beginning of the position of the secret column / field identifier in the logical log 300 (e.g., the beginning offset) as L1, and read or retrieve or obtain the corresponding column / field identifier (330A, 330B, 330C, 330D, etc.) in the logical log 300 to probe or search or check the "column identifier" column / field in the system catalog table (e.g., Figure 2 the "Column ID" column / field of the system catalog table 290).

[0055] In an example embodiment, when the DBMS engine (and / or the log manager) finds a match between the corresponding column / field identifier (330A, 330B, 330C, 330D, etc.) obtained from the logical log 300 and the value in the "column identifier" column / field in the system catalog table (e.g., Figure 2 the "Column ID" column / field of the system catalog table 290), the DBMS engine (and / or the log manager) can search the "owner" and / or "viewer" fields of the system catalog table to determine whether the user of the request (e.g., the logical log retrieval request) is one of the users in the "owner" and / or "viewer" fields of the system catalog table.

[0056] In an example embodiment, if the user of a request (e.g., a logical log retrieval request) is one of the users in the "owner" and / or "viewer" fields of the system catalog table, it can be understood that the secret / private column / field having an identifier corresponding to the obtained column / field identifier (330A, 330B, 330C, 330D, etc.) is visible to the user of the request (e.g., the logical log retrieval request). If the user of the request (e.g., the logical log retrieval request) is not any of the users in the "owner" and / or "viewer" fields of the system catalog table, it can be understood that the secret / private column / field having an identifier corresponding to the obtained column / field identifier (330A, 330B, 330C, 330D, etc.) is not visible to the user of the request (e.g., the logical log retrieval request).

[0057] In an example embodiment, when the DBMS engine (and / or the log manager) determines that the secret / private column / field corresponding to the obtained column / field identifier (330A, 330B, 330C, 330D, etc.) is visible to the user of the request, the DBMS engine (and / or the log manager) then reads or retrieves or obtains the corresponding length (340A, 340B, 340C, 340D, etc.) (e.g., two bytes, etc.) in the logical log 300 to determine the length of the secret / private data (350A, 350B, 350C, 350D, etc.), and marks the end position of the secret / private data (350A, 350B, 350C, 350D, etc.) in the logical log 300 as L2. Then, the DBMS engine (and / or the log manager) locates the secret / private data (350A, 350B, 350C, 350D, etc.) buffer in the logical log 300, e.g., from the start position / address (e.g., L1 + 32 + 16 + 2, assuming that in the logical log 300, the secret column identifier has a size of 32 bytes, the column identifier has a size of 16 bytes, and the length has a size of two bytes) to the end position / address (e.g., L2), to read or retrieve the secret / private data (350A, 350B, 350C, 350D, etc.). Then, the DBMS engine (and / or the log manager) will output the logical log (e.g., Figure 3B of 301, Figure 3D303) is returned to the (requesting) user equipment (e.g., via an interface of an application communicating with the DBMS engine). It should be understood that the logical logs (301, 303) can be the logical log 300, where for all (e.g., 301) or some (e.g., 303) of the secret / private columns / fields visible to the requesting user, the secret column identifier, column identification, and / or length information are removed. That is, when all of the secret / private columns / fields corresponding to the column identifications in the logical log 300 are visible to the requesting user equipment, the logical log 301 can be the output log. When some of the secret / private columns / fields corresponding to the column identifications in the logical log 300 are visible to the requesting user equipment, the logical log 303 can be the output log.

[0058] In an example embodiment, when the DBMS engine (and / or log manager) determines that the secret / private columns / fields corresponding to the obtained column / field identifications (330A, 330B, 330C, 330D, etc.) are not visible to the requesting user, the DBMS engine (and / or log manager) then reads, retrieves, or obtains the corresponding lengths (340A, 340B, 340C, 340D, etc.) (e.g., two bytes, etc.) in the logical log 300 to determine the lengths of the secret / private data (350A, 350B, 350C, 350D, etc.), and marks the end position of the secret / private data (350A, 350B, 350C, 350D, etc.) in the logical log 300 as L2. Then, the DBMS engine (and / or log manager) locates the secret / private data (350A, 350B, 350C, 350D, etc.) buffer in the logical log 300, e.g., from the start position / address to the end position / address (e.g., L2), to first read or retrieve the secret / private data (350A, 350B, 350C, 350D, etc.) and then mask it as masked data (360A, 360B, 360C, 360D, etc.). The start position / address can be, for example, L1 + 32 + 16 + 2, assuming that in the logical log 300, the secret column identifier has a size of 32 bytes, the column identification has a size of 16 bytes, and the length has a size of two bytes. Then, the DBMS engine (and / or log manager) outputs the logical log containing the masked data (360A, 360B, 360C, 360D, etc.) (e.g., Figure 3C 302 of Figure 3Dis returned to the (requesting) user (e.g., via an interface of an application communicating with the DBMS engine). In an example embodiment, the masked data may indicate that the data is encoded, encrypted to ciphertext, masked by adding (one or more) random values, and / or otherwise prevented from viewing the plaintext of the data. It should be understood that the logical logs (302, 303) may be the logical log 300, where for all (e.g., 302) or some (e.g., 303) of the secret / private columns / fields visible to the requesting user, the secret column identifiers, column identifiers, and length information are removed. That is, when all of the secret / private columns / fields corresponding to the column identifiers in the logical log 300 are not visible to the requesting user, the logical log 302 may be the output log. When some of the secret / private columns / fields corresponding to the column identifiers in the logical log 300 are visible to the requesting user, the logical log 303 may be the output log.

[0059] That is, based on the logical log 300, the output logical logs (301, 302, 303) may have removed all secret column identifiers (320A, 320B, 320C, 320D, etc.), column identifiers (330A, 330B, 330C, 330D, etc.), and length (340A, 340B, 340C, 340D, etc.) information therefrom. In the output logical logs (301, 302, 303), for the secret / private columns / fields (corresponding to the column identifiers in the logical log 300) visible to the requesting user, the secret / private data (350A, 350B, 350C, 350D, etc.) may be retained (from the logical log 300). In the output logical logs (301, 302, 303), for the secret / private columns / fields (corresponding to the column identifiers in the logical log 300) not visible to the requesting user, the original or plaintext secret / private data (350A, 350B, 350C, 350D, etc.) may not be retained (from the logical log 300), but rather masked data (360A, 360B, 360C, 360D, etc.) of the secret / private data (350A, 350B, 350C, 350D, etc.) may replace the secret / private data (350A, 350B, 350C, 350D, etc.) and be located in the output logical logs (301, 302, 303).

[0060] In an example embodiment, considering that the values of the secret column identifiers (320A, 320B, 320C, 320D, etc.) are 0xfffc, the column identifiers (330A, 330B, 330C, 330D, etc.) are 0x8001, and the secret / private data (350A, 350B, 350C, 350D, etc.) is 0x1234 (i.e., the secret / private data has a size of two bytes, or the size of the secret / private data is 0x0002, or the length is 0x0002). For such secret / private data, in the logical log 300, the recorded data can be 0xfffc800100021234. The algorithm described above can search and locate the secret column identifier 0xfffc in the logical log 300 (which indicates the existence of secret data corresponding to at least one secret / secret column / field). Then, the algorithm can read the column identifier 0x8001 from the logical log 300 and probe the system catalog table (e.g., Figure 2 of 290), then read the next two bytes (the size of the length), then find the value of the length (which is 0x0002), and then read two bytes to obtain / retrieve the secret data 0x1234. If the secret column data pair is visible to the (requesting) user's device, the original or plaintext secret data 0x1234 can be returned to the user (without information about the secret column identifier, column identifier, and length). If the secret column data pair is not visible to the (requesting) user's device, the original or plaintext secret data 0x1234 can be masked, and the masked data can be returned to the user (without information about the secret column identifier, column identifier, and length). For other data (without a secret column identifier (and corresponding column identifier and length) prefix), no action may be taken, and the plaintext of such data can be returned to the user's device. It should be understood that the data returned to the (requesting) user can be in the form of an output logical log, a data stream, or any other suitable format.

[0061] In an example embodiment, when no secret column / field identifier (320A, 320B, 320C, 320D, etc.) is detected or located in the logical log 300 (i.e., no data of the secret / private column / field is recognized), the DBMS engine (and / or log manager) can return the logical log 300 as an output logical log to the requesting user (to retrieve the logical log).

[0062] Figure 4 is a flowchart showing an example processing flow 400 of a logical log visibility control algorithm for a data privacy protection database system in an enclave according to at least some embodiments described herein.

[0063] It should be understood that, unless otherwise specified, the processing flow 400 disclosed herein can be performed by one or more processors (e.g., Figure 1 the processors of one or more of the terminal devices 110, 120, 130, and 140 of Figure 1 the server 150 of Figure 5 the central processing unit 505, and / or any other suitable processor).

[0064] It should also be understood that the processing flow 400 can include one or more operations, actions, or functions illustrated by one or more of the blocks 410, 420, 430, 440, 450, 460, 470, 480, and 490. These different operations, functions, or actions can, for example, correspond to software, program code, or program instructions executable by a processor, such that these functions are executed. Although shown as discrete blocks, obvious modifications can be made, e.g., two or more blocks can be reordered; more blocks can be added; and each block can be divided into additional blocks, combined into fewer blocks, or deleted according to the desired implementation. It should be understood that operations including initialization, etc., can be performed before the processing flow 400. For example, system parameters and / or application program parameters can be initialized. It should be understood that Figure 2 and Figures 3A to 3D the processes, operations, or actions described in

[0065] can be implemented or executed by a processor. The processing flow 400 can start at block 410.

[0066] At block 410 (request log retrieval), the processor can receive or obtain (e.g., from a user via a user interface of an application communicating with a DBMS or a DBMS engine) a request for retrieving a logical log (e.g., 300 of FIG. 3) of, for example, a fine-grained privacy protection database, where the DBMS or the database system of the database resides entirely within an enclave. The processing can proceed from block 410 to block 420.

[0067] At block 420 (parse log), the processor can parse or search the logical log to detect (unique) secret column identifiers in the logical log, and the processing can proceed from block 420 to block 430.

[0068] At block 450 (probe system directory table), the processor may read, obtain, or retrieve the corresponding column identifier (immediately following the identified secret column identifier) in the logical log. The processor may probe or search the system directory table (e.g., Figure 2 of 290) to find or locate the row / record in the system directory table that has a column identifier matching the column identifier retrieved / obtained in the logical log. The processor may then search or examine the located row / record in the system directory table to find or locate the information of the owner and / or the viewer(s). If the requesting user is one of the owner and / or the viewer(s), the secret column (data) corresponding to the column identifier (of the logical log or the system directory table) may be visible to the requesting user. If the requesting user is not any of the owner and / or the viewer(s), the secret column (data) corresponding to the column identifier (of the logical log or the system directory table) may be invisible to the requesting user. The process may proceed from block 450 to block 460.

[0069] At block 460 (column visible), if the secret column (data) corresponding to the column identifier (of the logical log or the system directory table) is visible to the requesting user device, the process may proceed from block 460 to block 470. If the secret column (data) corresponding to the column identifier (of the logical log or the system directory table) is invisible to the requesting user device, the process may proceed from block 460 to block 480.

[0070] At block 470 (retrieve secret data), the processor may read, obtain, or retrieve the corresponding length (immediately following the obtained or retrieved column identifier) in the logical log. The value of the length may indicate the size of the corresponding secret data (immediately following the obtained or retrieved length) in the logical log. The secret data is the data of the secret column corresponding to the column identifier. The processor may read, obtain, or retrieve the corresponding secret data based on the length information. The processor may also remove or delete the corresponding secret column identifier, column identifier, and length information (e.g., from the logical log). The process may return from block 470 to block 450 and repeat these processes until all identified or located secret column identifiers are processed.

[0071] At block 480 (masking secret data), the processor may read, obtain, or retrieve the corresponding length (immediately following the column identifier obtained or retrieved) in the logical log. The value of the length may indicate the size of the corresponding secret data (immediately following the length obtained or retrieved) in the logical log. The secret data is the data of the secret column corresponding to the column identifier. The processor may read, obtain, or retrieve the corresponding secret data based on the length information. The processor may mask the secret data (e.g., by replacing the secret data with masking data, or by masking the secret data in place, etc.). The processor may also remove or delete the corresponding secret column identifier, column identifier, and length information (e.g., from the logical log). The process may return from block 480 to block 450 and repeat these processes until all identified or located secret column identifiers are processed.

[0072] After processing all identified or located secret column identifiers, the process may proceed from block 440 (e.g., block 470 or block 480) to block 490. It should be understood that no action may be taken for data in the logical log that does not have a prefix of a secret column identifier (followed by the corresponding column identifier and length), and such data may be retained in the logical log (and / or returned to the user) without any modification.

[0073] At block 490 (distributing the log), the processor may return or distribute the output logical log to the requesting user (e.g., via the user interface of an application communicating with the DBMS or the DBMS engine). The output logical log may be (1) the original logical log updated at block 470 and / or block 480, (2) a new logical log generated or created based on the original logical log (e.g., a copy of the original logical log) and then updated at block 470 and / or block 480 (e.g., to remove the corresponding secret column identifier, the corresponding column identifier and length, and / or mask the secret data, etc.), (3) a data stream reflecting (1) or (2), i.e., the data stream (i) includes secret data and / or masking data (depending on visibility), (ii) includes data that does not have a prefix of a secret column identifier (followed by the corresponding column identifier and length), but (iii) does not include the secret column identifier (if any) and the corresponding column identifier and length, and / or (4) any other suitable format or form.

[0074] Figure 5 is a schematic structural diagram of an example computer system 500 arranged according to at least some embodiments described herein and suitable for implementing an electronic device (e.g., Figure 1 one of the servers or terminal devices shown in Figure 5 ). It should be understood that the computer system shown in

[0075] As depicted, computer system 500 may include a central processing unit (CPU) 505. The CPU 505 may perform various operations and processes based on programs stored in read-only memory (ROM) 510 or programs loaded from storage device 540 into random access memory (RAM) 515. The RAM 515 may also store various data and programs required for the operation of system 500. The CPU 505, ROM 510, and RAM 515 may be connected to each other via bus 520. Input / output (I / O) interface 525 may also be connected to bus 520.

[0076] Components connected to the I / O interface 525 may further include: an input device 530, which includes a keyboard, mouse, digital pen, graphics tablet, etc.; an output device 535, which includes a display (such as a liquid crystal display (LCD)), speakers, etc.; a storage device 540, which includes a hard disk, etc.; and a communication device 545, which includes a network interface card, such as a LAN card, modem, etc. The communication device 545 may perform communication processing via networks such as the Internet, WAN, LAN, LIN, cloud, etc. In an embodiment, a drive 550 may also be connected to the I / O interface 525. Removable media 555, such as magnetic disks, optical disks, magneto-optical disks, semiconductor memories, etc., may be installed on the drive 550 as needed, so that computer programs read from the removable media 555 can be installed in the storage device 540.

[0077] It should be understood that the processes described with reference Figure 4 to the flowcharts and / or the processes described in other figures may be implemented as computer software programs or implemented in hardware. A computer program product may include a computer program stored in a non-volatile computer-readable medium. The computer program includes program code for performing the methods shown in the flowcharts and / or GUI. In this embodiment, the computer program may be downloaded and installed from a network via the communication device 545, and / or may be installed via the removable media 555. When executed by the central processing unit (CPU) 505, the computer program may implement the above functions specified by the methods in the embodiments disclosed herein.

[0078] It should be understood that the disclosed and other solutions, examples, embodiments, modules, and functional operations described herein can be implemented in digital electronic circuits or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in a combination of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter affecting a machine-readable propagated signal, or a combination of one or more of them. The term "data processing apparatus" encompasses all apparatus, devices, and machines for processing data, including, for example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, the apparatus can include code that creates an execution environment for the computer programs being discussed, e.g., code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0079] A computer program (also referred to as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. The program can be stored in a part of a file that holds other programs or data (e.g., one or more scripts in a markup language document), stored in a single file dedicated to the program being discussed, or stored in multiple cooperating files (e.g., files that store one or more modules, subroutines, or portions of code). A computer program can be deployed to execute on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0080] The processes and logical flows described in this document can be executed by one or more programmable processors that execute one or more computer programs to perform functions by operating on input data and generating output. These processes and logical flows can also be executed by dedicated logic circuitry, and the apparatus can also be implemented as dedicated logic circuitry, e.g., a field-programmable gate array, an application-specific integrated circuit, etc.

[0081] Processors suitable for executing computer programs include, for example, general and special purpose microprocessors, as well as any one or more processors of any type of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing the instructions and data. Generally, a computer will also include one or more mass storage devices for storing data, such as, for example, magnetic disks, magneto-optical disks, or optical disks, or be operatively coupled to one or more mass storage devices for storing data to receive data therefrom or transfer data thereto, or both. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices such as erasable programmable read-only memory, electrically erasable programmable read-only memory, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and compact disc read-only memory and digital video disc read-only memory discs. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0082] It should be understood that different features, variations, and multiple different embodiments have been shown and described in various details. What is sometimes described in terms of specific embodiments in this application is for illustrative purposes only and is not intended to limit or imply that only one particular embodiment or multiple specific embodiments are contemplated. It should be understood that the present disclosure is not limited to any single specific embodiment or enumerated variation. Many modifications, variations, and other embodiments will occur to those skilled in the art, and these modifications, variations, and other embodiments are intended to and in fact are covered by the present disclosure. Indeed, the scope of the present disclosure should be determined by a proper legal interpretation and construction (including equivalents) of the present disclosure as would be understood by those skilled in the art from the complete disclosure presented at the time of filing.

[0083] Aspect:

[0084] It should be understood that any one of the aspects may be combined with each other.

[0085] Aspect 1. A database management system (DBMS) in an enclave for a data privacy protection database, the system comprising: a system catalog table; a logical log; and a DBMS engine configured to: parse the logical log based on a request for retrieving the logical log to detect at least one predetermined identifier, and for each predetermined identifier detected in the logical log: determine access control for the request with respect to a field in the data privacy protection database corresponding to a record in the system catalog table, retrieve secret data corresponding to the field when the access control indicates a first access control state, or mask the secret data corresponding to the field when the access control indicates a second access control state, and distribute the logical log with the retrieved or masked secret data based on the request.

[0086] Aspect 2. The system according to aspect 1, wherein for each predetermined identifier in the logical log, the logical log includes an identification of the field, a length of the secret data, and the secret data.

[0087] Aspect 3. The system according to aspect 2, wherein for each predetermined identifier in the logical log, the engine is further configured to remove the predetermined identifier, the identification of the field, and the length of the secret data from the logical log before the logical log is distributed.

[0088] Aspect 4. The system according to aspect 2, wherein the record in the system catalog table includes an identification of the field and one or more user identifications.

[0089] Aspect 5. The system according to aspect 4, wherein the engine is further configured to: determine access control for the request based on the one or more user identifications when the identification of the field in the record matches the identification of the field in the logical log.

[0090] Aspect 6. The system according to aspect 5, wherein the engine is further configured to: configure the access control to the first access control state when the request is from a first user corresponding to the one or more user identifications, and configure the access control to the second access control state when the request is from a second user not corresponding to the one or more user identifications.

[0091] Aspect 7. The system according to any one of aspects 1 to 6, wherein the first access control state indicates that the field is visible to the user of the request, and the second access control state indicates that the field is invisible to the user.

[0092] Aspect 8. The system according to any one of aspects 1 to 7, wherein the entire system is in the enclave for execution at runtime.

[0093] Aspect 9. The system according to any one of Aspects 1 to 8, wherein the data privacy protection database is a fine-grained data privacy protection database.

[0094] Aspect 10. A method for data privacy control of a data privacy protection database, the method comprising: parsing, by a database management system (DBMS) in an enclave, a logical log based on a request for retrieving the logical log to detect at least one predetermined identifier; for each predetermined identifier detected in the logical log: determining an access control for the request with respect to a field in the data privacy protection database corresponding to a record in a system catalog table, retrieving secret data corresponding to the field when the access control indicates a first access control state, or masking the secret data corresponding to the field when the access control indicates a second access control state, and distributing the logical log with the retrieved or masked secret data based on the request.

[0095] Aspect 11. The method according to Aspect 10, wherein for each predetermined identifier in the logical log, the logical log includes an identification of the field, a length of the secret data, and the secret data.

[0096] Aspect 12. The method according to Aspect 11, further comprising: for each predetermined identifier in the logical log, removing the predetermined identifier, the identification of the field, and the length of the secret data from the logical log before distributing the logical log.

[0097] Aspect 13. The method according to Aspect 11, wherein the record in the system catalog table includes an identification of the field and one or more user identifications.

[0098] Aspect 14. The method according to Aspect 13, further comprising: determining an access control for the request based on the one or more user identifications when the identification of the field in the record matches the identification of the field in the logical log.

[0099] Aspect 15. The method according to Aspect 14, further comprising: configuring the access control to the first access control state when the request is from a first user corresponding to the one or more user identifications; and configuring the access control to the second access control state when the request is from a second user not corresponding to the one or more user identifications.

[0100] Aspect 16. A non-transitory computer-readable medium storing computer-executable instructions that, when executed, cause one or more processors to perform operations including: parsing, by a database management system (DBMS) in an enclave, a logical log based on a request for retrieving the logical log to detect at least one predetermined identifier; for each predetermined identifier detected in the logical log: determining an access control for the request with respect to a field corresponding to a record in a system catalog table in a data privacy protection database, retrieving secret data corresponding to the field when the access control indicates a first access control state, or masking the secret data corresponding to the field when the access control indicates a second access control state, and distributing the logical log with the retrieved or masked secret data based on the request.

[0101] Aspect 17. The computer-readable medium according to aspect 16, wherein for each predetermined identifier in the logical log, the logical log includes an identification of the field, a length of the secret data, and the secret data.

[0102] Aspect 18. The computer-readable medium according to aspect 17, the operations further including: for each predetermined identifier in the logical log, removing the predetermined identifier, the identification of the field, and the length of the secret data from the logical log before distributing the logical log.

[0103] Aspect 19. The computer-readable medium according to aspect 17, wherein the record in the system catalog table includes an identification of the field and one or more user identifications.

[0104] Aspect 20. The computer-readable medium according to aspect 19, the operations further including: when the identification of the field in the record matches the identification of the field in the logical log, determining an access control for the request based on the one or more user identifications.

[0105] The terms used in this specification are intended to describe particular embodiments and are not intended to be limiting. Unless otherwise expressly stated, the terms "a / an" and "the" also include the plural forms. When used in this specification, the term "comprises and / or comprising" specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, and / or components.

[0106] Regarding the foregoing description, it should be understood that changes may be made in the details, especially in the construction materials used and the shape, size, and arrangement of the parts, without departing from the scope of the disclosure. This specification and the described embodiments are merely exemplary, and the true scope and spirit of the disclosure are indicated by the appended claims.

Claims

1. A database management system (DBMS) in an enclave for a data privacy - protected database, the system comprising: A system catalog table; A logical log; And A DBMS engine, the DBMS engine being configured to: Parse the logical log based on a request for retrieving the logical log to detect at least one predetermined identifier; For each predetermined identifier detected in the logical log: Determine access control for the request with respect to fields in the data privacy - protected database corresponding to records in the system catalog table, and When the access control indicates a first access control state, retrieve the secret data corresponding to the field, or when the access control indicates a second access control state, mask the secret data corresponding to the field, and Distribute the logical log with the retrieved or masked secret data based on the request.

2. The system according to claim 1, wherein For each predetermined identifier in the logical log, the logical log includes an identification of the field, a length of the secret data, and the secret data.

3. The system according to claim 2, wherein, For each predetermined identifier in the logical log, the engine is further configured to remove the predetermined identifier, the identification of the field, and the length of the secret data from the logical log before the logical log is distributed.

4. The system according to claim 2, wherein, The records in the system catalog table include an identification of the field and one or more user identifications.

5. The system according to claim 4, wherein The engine is further used to: When the identification of the field in the record matches the identification of the field in the logical log, determine the access control for the request based on the one or more user identifications.

6. The system according to claim 5, wherein The engine is further used to: When the request comes from a first user corresponding to the one or more user identifications, configure the access control to the first access control state; And When the request comes from a second user not corresponding to the one or more user identifications, configure the access control to the second access control state.

7. The system according to claim 1, wherein The first access control state indicates that the field is visible to the user of the request, and the second access control state indicates that the field is invisible to the user.

8. The system according to claim 1, wherein, The entire system is in the enclave for execution at runtime.

9. A method for data privacy control of a data privacy - protected database, the method comprising: Parsing, by a database management system (DBMS) in an enclave, the logical log based on a request for retrieving the logical log to detect at least one predetermined identifier; For each predetermined identifier detected in the logical log: Determine access control for the request with respect to fields in the data privacy - protected database corresponding to records in a system catalog table, and When the access control indicates a first access control state, retrieve the secret data corresponding to the field, or when the access control indicates a second access control state, mask the secret data corresponding to the field; and Distribute the logical log with the retrieved or masked secret data based on the request.

10. The method according to claim 9, wherein, For each predetermined identifier in the logical log, the logical log includes an identification of the field, a length of the secret data, and the secret data.

11. The method of claim 10, further comprising: For each predetermined identifier in the logical log, removing the predetermined identifier, the identification of the field, and the length of the secret data from the logical log before distributing the logical log.

12. The method according to claim 10, wherein, The record in the system catalog table includes the identification of the field and one or more user identifications.

13. The method of claim 12, further comprising: When the identification of the field in the record matches the identification of the field in the logical log, determining access control for the request based on the one or more user identifications.

14. The method of claim 13, further comprising: When the request is from a first user corresponding to the one or more user identifications, configuring the access control to the first access control state; And When the request is from a second user not corresponding to the one or more user identifications, configuring the access control to the second access control state.

15. The method according to claim 9, wherein, The first access control state indicates that the field is visible to the user of the request, and the second access control state indicates that the field is invisible to the user.

16. A non-transitory computer-readable medium having computer-executable instructions stored thereon that, when executed, cause one or more processors to perform operations including the following: Parsing the logical log by a database management system (DBMS) in an enclave based on a request for retrieving the logical log to detect at least one predetermined identifier; For each predetermined identifier detected in the logical log: Determining access control for the request with respect to a field corresponding to a record in a system catalog table in a data privacy protection database, and When the access control indicates a first access control state, retrieving the secret data corresponding to the field, or when the access control indicates a second access control state, masking the secret data corresponding to the field; and Distributing the logical log with the retrieved or masked secret data based on the request.

17. The computer-readable medium according to claim 16, wherein, For each predetermined identifier in the logical log, the logical log includes an identification of the field, a length of the secret data, and the secret data.

18. The computer-readable medium of claim 17, the operations further comprising: For each predetermined identifier in the logical log, removing the predetermined identifier, the identification of the field, and the length of the secret data from the logical log before distributing the logical log.

19. The computer-readable medium according to claim 17, wherein, The record in the system catalog table includes the identification of the field and one or more user identifications.

20. The computer-readable medium of claim 19, the operations further comprising: When the identification of the field in the record matches the identification of the field in the logical log, determining access control for the request based on the one or more user identifications.

Images