Statistical information visibility control in enclave database
By implementing a fully hardware-encrypted database system in a trusted execution environment, using logical log encoding and mask control, the performance bottlenecks and data privacy protection problems of the hardware-encrypted database system are solved, and efficient database statistical information protection and query optimization are achieved.
Patent Information
- Application Number
- CN202411371414.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-12-15
- Filing Date
- 2024-09-29
- Publication Date
- 2025-07-08
AI Technical Summary
Conventional hardware-encrypted database systems have performance bottlenecks when performing database operations, especially due to TEE memory limitations and high I/O costs, it is difficult to implement a fully hardware-encrypted database system, and the privacy protection of database statistics is difficult to implement without affecting performance.
By residing the entire database management system in a trusted execution environment, adopting a full hardware encryption architecture, using logical log encoding and mask control, it realizes fine-grained data privacy protection, controls the visibility of database statistics, and avoids high I/O loads of client-side cryptography.
It effectively protects the privacy of database statistics without affecting performance, reduces I/O load, and improves query efficiency and data security.
Smart Images

Figure CN120277702A_ABST
Abstract
Description
Technical Field
[0001] The embodiments described herein generally relate to database systems, and more particularly, to methods for creating and accessing entries therein when the visibility of statistical information is controlled. Background Art
[0001] 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 the authenticated DBMS operator code within an enclave. Once the ciphertext (e.g., via the 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 calculations or operations on the plaintext, then encrypts the calculated plaintext (if necessary), and then replies to the DBMS.
[0002] Generally, the design of P-HE databases is based on enclave constraints, such as Trusted Execution Environment (TEE) memory limitations or restrictive constraints. Therefore, it is impractical to authenticate the entire DBMS into the enclave to implement a full hardware encryption (F-HE) database system for runtime execution because the input / output (I / O) costs in the P-HE database between the enclave and the DBMS can severely affect system performance. Summary of the Invention
[0002] The present disclosure relates to database systems and methods for creating and accessing entries therein, particularly when the visibility of statistical information is controlled.
[0003] The recently increased TEE memory can enable an F-HE architecture. The features in the embodiments disclosed herein can provide other ways to 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.
[0004] 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 storage (such as system and physical logs) that are used internally by the DBMS and do not have an explicit retrieval interface 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 being loaded into memory and participating in processor (such as a CPU, etc.) calculations, being written to and read from disk I / O as a log file, and being transferred between replicas via network I / O. In the F-HE paradigm, any operation related to the redo log cannot 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 transmissions can be protected, for example, by the remote attestation - transport layer security (RA-TLS) protocol.
[0005] It should also be understood that in the F-HE database architecture, for data structures and data storage with some explicit retrieval interface (such as 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 (such as using the RA mechanism, etc.) in conventional P-HE databases. 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 associated with client-side cryptography.
[0006] Database administrators can use database statistics to optimize access paths within the database, thereby improving query efficiency and limiting input / output (I / O) load. Statistics can include, for example, frequency data of the values of entries within the database, histogram data characterizing the entries in the database, cardinality data, or other such data. In some databases, statistics such as frequency data and histogram data can be considered sensitive and thus require security. Embodiments of the present invention allow for the implementation of user-defined database statistics security and masking based on the user-defined security. Additionally, this security can be executed in a database that resides entirely within a trusted execution environment (TEE), thereby complementing the protection provided by the TEE for data structures and data storage without an explicit retrieval interface. By using the TEE to control access to database statistics, the database can be protected without the high I / O load typically associated with some hardware encryption schemes.
[0007] In an embodiment, a method of operating a database includes: receiving, at a parser of a database management system (DBMS), a request for database statistics regarding a database table column from a source, where the DBMS is in a trusted execution environment. The method further includes determining a visibility level of the database statistics regarding the database table column to the source based on a comparison of the source with an authorized viewer of the database statistics. The method further includes providing the requested database statistics to the source, where the database statistics provided to the source are based on the visibility level of the database statistics to the source.
[0008] In an embodiment, the database statistics are frequency data of entries for a database table column. In an embodiment, the database table column has a security level, and the frequency data provided to the source is further based on the security level. In an embodiment, when the source is not an authorized viewer and the security level is a low security level, the frequency data provided to the source based on the security level includes numerical frequency data with plaintext values and column data with plaintext values. In an embodiment, when the source is not an authorized viewer and the security level is a medium security level, the frequency data provided to the source based on the security level includes numerical frequency data with plaintext values and column data with masked values. In an embodiment, when the source is not an authorized viewer and the security level is a high security level, the frequency data provided to the source based on the security level includes numerical frequency data with masked values and column data with masked values.
[0009] In an embodiment, the database statistics are histogram data of entries for a database table column. In an embodiment, the database table column has a security level, and the characteristics of the histogram data provided to the source are further based on the security level. In an embodiment, when the source is not an authorized viewer and the security level is a low security level, the histogram data provided to the source based on the security level includes numerical y-axis data with plaintext values and x-axis value data with plaintext values. In an embodiment, when the source is not an authorized viewer and the security level is a medium security level, the histogram data provided to the source based on the security level includes numerical y-axis data with plaintext values and x-axis value data with masked values. In an embodiment, when the source is not an authorized viewer and the security level is a high security level, the histogram data provided to the source based on the security level includes numerical y-axis data with masked values and x-axis value data with masked values.
[0010] In an embodiment, the method further includes generating, within the DBMS, a database table column that includes a column identifier for the database table column, an authorized viewer for the database table column, and a security level of the database table column.
[0011] In an embodiment, a database management system (DBMS) is located within a trusted execution environment. The DBMS includes database table columns. The DBMS also includes a parser configured to: receive a request for database statistics regarding a database table column from a source, and determine a visibility level of the database statistics regarding the database table column to the source based on a comparison of the source with an authorized viewer of the database statistics. The DBMS further includes a runtime environment configured to provide the requested database statistics to the source, wherein the database statistics provided to the source are based on the visibility level of the database statistics to the source. In an embodiment, the database table column includes a column identifier for the database table column, an authorized viewer of the database table column, and a security level of the database table column, and the database statistics provided to the source are further based on the security level. In an embodiment, the database statistics are frequency data for the database table column. In an embodiment, the database statistics are histogram data for the database table column.
[0012] In an embodiment, a non-transitory computer-readable medium stores computer-executable instructions thereon that, when executed, cause one or more processors to perform operations. The operations include: providing a database management system (DBMS) within a trusted execution environment; receiving, at a parser of the DBMS, a request for database statistics regarding a database table column from a source, determining a visibility level of the database statistics regarding the database table column to the source based on a comparison of the source with an authorized viewer of the database statistics; and providing the requested database statistics to the source. The database statistics provided to the source are based on the visibility level of the database statistics to the source. In an embodiment, the database table column further includes a security level, and the database statistics provided to the source are further based on the security level. In an embodiment, the database statistics are frequency data of the database table column. In an embodiment, the database statistics are histogram data of the database table column. BRIEF DESCRIPTION OF THE DRAWINGS
[0013] The accompanying 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 groups of boxes, or other shapes) represent an example of the 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 that is shown as an internal component of one element can be implemented as an external component of another element, and vice versa. The following accompanying drawings are described in a non - restrictive and non - exhaustive manner. The components in the figures are not necessarily drawn to scale, but the emphasis is placed on illustrating the principles. In the following detailed description, the embodiments are described only by way of illustration, since various changes and modifications may be apparent to those skilled in the art from the following detailed description.
[0014] Figure 1 A schematic view of an example data privacy - protected database system according to an embodiment is shown.
[0015] Figure 2 A schematic diagram of a database system arranged according to at least some of the embodiments described herein is shown.
[0016] Figure 3 A schematic diagram of a database system arranged according to at least some of the embodiments described herein is shown.
[0017] Figure 4 A schematic diagram of a database system arranged according to at least some of the embodiments described herein is shown.
[0018] Figure 5 The security levels and the data displayed arranged according to at least some of the embodiments described herein are shown.
[0019] Figure 6 A flowchart of a method for creating a database including shieldable columns arranged according to at least some of the embodiments described herein is shown.
[0020] Figure 7 A flowchart of a method for accessing statistical data of a database arranged according to at least some of the embodiments described herein is shown. Detailed Description
[0021] The present disclosure relates to database systems, and specifically, to methods for creating and accessing entries therein when the visibility of statistical information is controlled.
[0022] 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. Additionally, unless otherwise stated, the description of each subsequent drawing can refer to features from one or more of the previous drawings to provide a clearer context and a more substantial explanation for the current exemplary embodiment. Nevertheless, the exemplary embodiments described in the detailed description, the drawings, and the claims are not intended to be limiting. Other embodiments can be utilized and other changes can 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 illustrated 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.
[0023] 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 constructions are not described in detail to avoid obscuring the present disclosure with unnecessary details. Thus, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as a basis for the claims and as a representative basis for teaching one of ordinary skill in the art to employ the present disclosure in various appropriate detailed structures in a variety of ways.
[0024] 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.
[0025] 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 claim. Additionally, no element is essential to the practice of the present disclosure unless explicitly described herein as "critical" or "necessary".
[0026] As mentioned herein, a "database" is a term that 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 interact with end users. As mentioned herein, a "database server" is a term that 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 typically provide database-server functionality, and some DBMSs can rely entirely on the client-server model for database access. It should also be understood that a DBMS can additionally include core facilities provided for managing the database, and the sum of the database, the DBMS, and associated applications can be referred to as a database system. In an example embodiment, the database system can be a relational database system that 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.
[0027] As mentioned herein, a "DBMS engine" or "database engine" is a term that can refer to 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).
[0028] As mentioned herein, an "enclave" is a term and can refer to a Trusted Execution Environment (TEE) that can protect sensitive data and code, such as protecting against 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 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 used to help 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 can include the computer owner or operator themselves). This can be done by implementing confidential architecture security, which 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 applications executed within 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 level of security for trusted applications running on a device than the operating system.
[0029] As mentioned herein, "fine-grained" or "granularity" data privacy protection is a term that can refer to a method, procedure, or system for protecting data privacy for a particular part or aspect of 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 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 the data privacy of a particular part or aspect of the database table.
[0030] As mentioned herein, the "logical log" in a database is a term that can 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.), which is used to preserve 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 term and can refer to a log file containing the content of each changed row / record. Generally, logical log records do not refer to entering the changed row / record, but rather to entering the commands (e.g., SQL statements, etc.) that caused the row / record to change (e.g., insert, update, and / or delete statements, etc.). The logical log can describe the changes in the form of record images or commands (e.g., SQL statements, etc.). Physical log records mean entering the content of each changed row / record. The physical log can describe the changes in a way that is more oriented towards underlying data block operations. In an exemplary embodiment, the logical log can include an audit log, and the physical log can include a redo log.
[0031] As mentioned herein, the "system catalog" table in a database is a term that can refer to the (multiple) tables and / or (multiple) views that describe the database structure. It should be understood that the system catalog table can refer to a data dictionary that can contain everything the database knows about itself.
[0032] As mentioned herein, the "structured data" in a database is a term that can 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 structured data can be classified as quantitative data and can be highly organized and easily understandable in machine language. Structured data can be easily entered, 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 term that can refer to complex, qualitative, and / or unorganized data, which may not conform to any one specific standard (e.g., 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 string can have a mixed data type that cannot be placed in 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.
[0033] Figure 1Shows a schematic view of an example data privacy protection database system according to an embodiment. 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 computers, 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, networks, and servers are shown. The embodiments described herein are not limited to the number of terminal devices, networks, and / or servers described. That is, the number of terminal devices, networks, and / or servers described herein is provided for illustrative purposes only and is not intended to be limiting.
[0034] 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, desktop computers, and / or any other suitable electronic devices.
[0035] 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), the cloud, etc. Network 160 may be implemented via various types of connections, such as wired communication links, wireless communication links, fiber optic cables, etc.
[0036] 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.
[0037] A user may interact with server 150 via network 160 using one or more of terminal devices 110, 120, 130, and 140. Various application programs or their localized interfaces, such as database application programs, social media application programs, online shopping application programs, etc., may be installed on terminal devices 110, 120, 130, and 140.
[0038] 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). Therefore, 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.
[0039] It should also be understood that when the service is not remotely executed, the system 100 may optionally include the network 160, while including the terminal devices 110, 120, 130, and 140 or the server 150.
[0040] In addition, it should be understood that the terminal devices 110, 120, 130, and 140 and the server 150 may each include one or more processors, a memory, and a storage device storing one or more programs. Each of the terminal devices 110, 120, 130, and 140 and / or the server 150 may also each include an Ethernet connector, a Wi-Fi receiver, etc. When executed by one or more processors, the one or more programs may 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 may 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.
[0041] Figure 2 A schematic diagram of a database system according to an embodiment is shown. As Figure 2 shown, a database management system (DBMS) 200 is set inside the enclave 202, for example, storing and executing entirely using the resources of the enclave 202. The user 204 creates a database table that includes masked columns defined in the secret column directory 206. The secret column directory 206 includes the column identifier 208 of the masked column, the owner 210 of the database table, the permitted viewers 212 of the masked column, and the security level 214 of the masked column.
[0042] The DBMS 200 is a database management system configured to handle the generation, creation, operation, access, manipulation, search, and / or retrieval of entries in the database (such as database tables, their columns, etc.). The DBMS 200 may be set inside the enclave 202, for example, by storing and executing entirely using the resources of the enclave 202. The enclave 202 may be a trusted execution environment (TEE), which may be a set of encrypted system resources (such as memory, input / output, a processor (such as a central processing unit), etc.). The DBMS 200 may include a database engine, such as an SQL engine.
[0043] User 204 is a user of a database that includes DBMS 200. User 204 can be any suitable database user with the privilege to create entries in the database. User 204 generates one or more database entries that include at least one maskable column. A maskable column is a column designated by User 204 as having its visibility controlled. Visibility control of a maskable column can be performed for any suitable reason, such as the sensitivity or confidentiality of the data it contains, policies, regulations, rules, or laws related to the processing of the data it contains, etc. The visibility of a maskable column can be controlled relative to a request for statistical data of the column, for example, a request by an administrator or other user of the database, such as when the administrator optimizes the access path in the database. The characteristics of the maskable column and the data masked by the maskable column can be stored in the Secret Column Directory 206. The Secret Column Directory 206 can include any suitable data required to control the masking of the maskable column, such as a column identifier 208, an indication of the owner 210, a definition of one or more permitted viewers 212, and optionally a security level 214 of the maskable column.
[0044] The column identifier 208 is an identifier of the maskable column. The column identifier can be any suitable data that identifies the maskable column, such as a flag set on the column, a link or pointer, an identification number, a memory location, etc. For example, the column identifier 208 can be referred to determine whether a request for statistical data is a request for statistical data from a maskable column. The column identifier 208 can be associated with the maskable column when the maskable column is created, when User 204 edits the column and sets it as a maskable column, etc.
[0045] The owner 210 is an identifier of the creator of the maskable column. The owner 210 can be an identifier that associates User 204 with the maskable column. In an embodiment, for example, the owner 210 can be referred to determine whether to permit or deny editing of the maskable column, changing the column flag to a maskable column, etc. In an embodiment, when determining the visibility of statistical data or its components, the owner 210 can be referred to permit User 204 to view the statistical data of the maskable column without any masking of the data it contains.
[0046] The permitted viewer 212 defines a database statistics request source that is permitted to view database statistics without masking some or all of the statistics for maskable columns. The permitted viewer 212 can be any suitable definition of a request source that is permitted to receive unmasked statistics when requesting statistics for maskable columns identified by the column identifier 208. The permitted viewer 212 can include, for example, a list of users of the database system, one or more user categories of the database system, a list of permitted request sources (such as specific functions, programs, interfaces, etc.), one or more categories defining permitted request sources, etc. The permitted viewer 212 can be referenced to compare the source of a request for statistics on a maskable column to determine whether the request source is permitted to receive the statistics in an unmasked format, such as discussed below and shown in Figure 3 and Figure 4 as shown.
[0047] A security level 214 can optionally be provided to control the visibility of the database statistics to request sources other than the defined permitted viewer 212. The security level 214 can be a definition of the visibility of the maskable columns to request sources other than the request sources identified by the permitted viewer 212. The security level 214 can be, for example, a selected one of a plurality of predefined levels defined in the DBMS 200 or its interface, such as a high, medium, or low security level. In an embodiment, the security level 214 is, for example, a definition of column-specific visibility according to one or more rules provided by the user 204. The security level can define which characteristics of the statistics (such as numerical frequency values, column data, x-axis and y-axis values of a histogram, etc.) are masked or unmasked when provided in response to a request from a request source that is not defined as a permitted viewer 212. In an embodiment, the security level 214 can be omitted, and when requesting statistics for maskable columns, request sources other than those according to the permitted viewer 212 can only be provided with fully masked statistics. A non-limiting example of a set of low, medium, and high security levels 214 showing the respective visibility of specific characteristics of frequency data and histogram data is described below and shown in Figure 5 as shown.
[0048] Figure 3 shows a schematic diagram of a database system according to an embodiment. Figure 3Shows that the request source 300 requests statistical data of a database table, and the database table includes maskable columns defined in a secret column directory 206 within a DBMS 200 set in an enclave 202. The request source 300 provides a request for statistical data to a parser 302 of the DBMS 200. The parser 302 determines whether the request source 300 is an allowed viewer 212 for that column identifier 208 defined in the secret column directory 206. When it is determined that the request source 300 is included in the allowed viewer 212, the parser 302 may instruct the runtime environment 304 to provide the statistical data to the request source 300 without any masking of the statistical data.
[0049] The request source 300 can be any suitable source of a request for statistical data from a database. In Figure 3 the embodiment shown, the request source 300 is a request source included in the allowed viewer 212. The request source 300 can be, for example, a DBMS 200 user other than the user 204, an automatic call for statistical data, a call for statistical data through an API, or any other suitable source of a request for statistical data. The statistical data can be any suitable statistical data about the database content, such as frequency data, histogram data, cardinality data, etc. for one or more columns of a database table. In an embodiment, the statistical data includes frequency data of database table columns. In an embodiment, the statistical data includes histogram data of database table columns. The request source 300 can request the statistical data for any suitable reason, such as adjusting the path layout in the database, improving the efficiency of retrieving entries from the database, displaying the statistical data itself, etc.
[0050] At the parser 302 set within the DBMS 200, a request from the request source 300 is received. The parser 302 is a module of the DBMS 200, configured to receive the request and process the request and the encrypted column directory 206 to determine the visibility level of the statistical data involved in the request. The parser 302 can refer to the column identifier 208 to determine whether the request involves a maskable column. When the request involves statistical data of a specific maskable column, the parser 302 can refer to the owner 210 of the maskable column and the allowed viewer 212 to compare the request source 300 with the set of request sources that can obtain unmasked statistical data of the maskable column according to the owner 210 and the allowed viewer 212. In Figure 3In the embodiment shown, the parser 302 compares the request source 300 with the permitted viewers 212 defined in the encrypted column directory and finds that the request source 300 is included therein and is thus permitted to receive unmasked statistical data from the maskable column identified by the column identifier 208. When the request source 300 is permitted to receive unmasked statistical data, the parser 302 may instruct the runtime environment 304 to provide the statistical data in response to a request from the request source 300 in an unmasked format (e.g., as plain text data).
[0051] The runtime environment 304 is a module of the DBMS 200 configured to respond to requests from the request source 300 based on the visibility level determined by the parser 302. The runtime environment 304 may be any suitable module for interfacing with the request source 300 to respond to requests, such as an application, an application programming interface (API), or any other suitable module. The runtime environment 304 may be provided within the DBMS 200 within the enclave 202. When the visibility level of the statistical data is fully visible to the request source 300, e.g., when the request source 300 is included in the permitted viewers 212, the runtime environment 304 may present the statistical data in response to the request in a format that does not mask the statistical data or any of its components.
[0052] Figure 4 A schematic diagram of a database system according to an embodiment is shown. Figure 4 A second request source 400 is shown requesting statistical data for a database table including a maskable column. In Figure 4 the embodiment shown, the second request source 400 is not included in the permitted viewers 212. The second request source 400 provides a request for the statistical data to the parser 302. The parser 302 references the second request source 300 against the permitted viewers 212. When it is determined that the second request source 400 is not included in the permitted viewers 212, the parser 302 may also reference the security level 214. The parser 302 may determine the visibility level of the statistical data for the maskable column based on the security level 214 and instruct the runtime environment 304 to present the statistical data for the maskable column based on the determined visibility level.
[0053] The second request source 400 can be any suitable source of requests for statistical data from the database that is not identified among the permitted viewers 212. The second request source 400 can be, for example, a DBMS 200 user other than the user 204 or the request source 300, an automatic invocation of statistical data, an invocation of statistical data via an API, or any other suitable source of requests for statistical data. The statistical data can be any suitable statistical data regarding the database content, such as frequency data, histogram data, cardinality data, etc. for one or more columns of a database table. In an embodiment, the statistical data is frequency data of a database table column. In an embodiment, the statistical data is histogram data of a database table column. The second request source 400 can request the statistical data for any suitable reason, such as adjusting the path layout in the database, improving the efficiency of retrieving entries from the database, displaying the statistical data itself, etc.
[0054] In Figure 4 the embodiment shown, the parser 302 receives a request from the second request source 400 and processes the request and the encrypted column directory 206 to determine the visibility level of the statistical data involved in the request. The parser 302 refers to the column identifiers 208 to determine whether the request involves a maskable column. When the request involves statistical data for a particular maskable column, the parser 302 can examine the owner 210 and the permitted viewers 212 of the maskable column to compare the second request source 400 with the set of request sources that can obtain unmasked statistical data for the maskable column. In Figure 4 the embodiment shown, according to the owner 210 and the permitted viewers 212, the second request source is not a permitted viewer. In Figure 4 the embodiment shown, the parser 302 further refers to the security level of the maskable column to determine the visibility level of the statistical data. In an alternative embodiment, when it is determined at the parser 302 that the second request source is not a permitted viewer according to the owner 210 and the permitted viewers 212, the visibility level of the data can be according to a global policy, such as providing fully masked data to the runtime environment 304 without the need to refer to the security level of a particular maskable column.
[0055] The visibility level of statistical data can be fully visible, such as presenting statistical data in clear text; partially masked, i.e., masking some characteristics of the statistical data; or fully masked, i.e., masking all characteristics of the statistical data. The masking can be any suitable data masking, such as hiding or omitting these characteristics, replacing the characteristics with scrambled or encrypted data or meaningless generated data, or any other suitable means to prevent the masked characteristics from being seen. The visibility level can be fully visible to the request source identified as the owner 210 or the approved viewer 212. When the request source is not identified as the owner 210 or the approved viewer 212, the masking can be based on a general or default policy (such as fully masking all data), or based on the security level 214 specific to the columns that can be masked. For example, when the request source is not identified as the owner 210 or the approved viewer 212, the security level 214 can specify the visibility level of the statistical data, i.e., fully visible, fully masked, or partially masked. The security level 214 can further define the characteristics of the statistical data to be masked in the case where the statistical data is to be partially masked, as described specifically for the medium security level 504 below and shown in Figure 5 as shown.
[0056] The runtime environment 304 presents the statistical data according to the visibility level provided by the parser 302. In the Figure 4 embodiment shown, when the second requester 400 is not the owner 210 or the authorized viewer 212, the runtime environment presents the statistical data according to the visibility level, which is, for example, unmasked (such as clear text data) or partially or fully masked according to the global policy or the security level 214.
[0057] Figure 5 shows the security level and the data displayed according to an embodiment. In the Figure 5 embodiment shown, the security level includes a low security level, a medium security level, and a high security level.
[0058] The security level is a set of one or more rules that manage the visibility of the statistical data of columns that can be masked when a request source not included among the licensed viewers of the columns that can be masked makes a request. Figure 5 The security level and the associated statistical information visibility shown in are exemplary embodiments, and the security level can include more or fewer levels that define the visibility suitable for the sensitivity of the data, the possible request sources, etc. The number of security levels and the statistical data visibility based on each corresponding security level can be customized to provide the desired granularity and data privacy suitable for the database in which the security level is implemented.
[0059] In Figure 5In the security level scheme shown, a low security level can be used for at least some maskable database columns. In particular, the low security level can be used for columns containing data with very low sensitivity, confidentiality, or privacy requirements, etc. The low security level can allow for visibility of all aspects of the statistical data of the database column. For frequency data, the visibility of the statistical data at the low security level can include providing the frequency data in fully visible form, such as plaintext data. The frequency data provided in plaintext data can include the values themselves and the specific frequencies of these values. For histogram data, the visibility of the statistical data at the low security level can include providing the histogram data in fully visible form, such as plaintext data. The histogram data provided in plaintext data can include the x-axis values of the histogram and the numeric y-axis data.
[0060] In Figure 5 In the security level scheme shown, a medium security level can be used for at least some maskable database columns. In particular, the medium security level can be used for columns containing data with medium sensitivity, confidentiality, or privacy requirements, such as some business records, etc. The medium security level can allow for visibility of some aspects of the statistical data of the database column while masking specific values included in the database column that can be discerned from the statistical data. For frequency data, the visibility of the statistical data at the medium security level can include providing the frequency data such that the values themselves are masked while the specific frequencies of these values can be provided in visible form, such as plaintext data. The masking of values in the frequency data can include hiding or omitting these values, replacing these values with scrambled or meaningless generated data, or any other suitable means of preventing the masked values from being seen. For histogram data, the visibility of the statistical data at the medium security level can include providing the histogram data such that the x-axis values are masked while the numeric y-axis data of the histogram can be provided in visible form, such as plaintext data. The masking of values in the frequency data can include hiding or omitting these values, replacing these values with scrambled or encrypted data or meaningless generated data, or any other suitable means of preventing the masked values from being seen.
[0061] In Figure 5In the security level scheme shown, a high security level can be used for at least some shieldable database columns. In particular, a medium security level can be used for columns containing data with high or extreme sensitivity, confidentiality, or privacy requirements, such as personal identification information, patient health data, salary data, highly confidential business records, etc. A high security level can mask the visibility of all aspects of statistical data. For frequency data, the visibility of statistical data at a high security level can include providing frequency data such that both the values and the specific frequencies of these values are masked. The masking of values in frequency data can include hiding or omitting these values, replacing these values with scrambled data or meaningless generated data, or any other suitable means of preventing the masked values from being seen. For histogram data, the visibility of statistical data at a high security level can include providing histogram data such that both the x-axis values and the numeric y-axis data of the histogram are masked. The masking of values in frequency data can include hiding or omitting these values, replacing these values with scrambled data or meaningless generated data, or any other suitable means of preventing the masked values from being seen.
[0062] Figure 6 FIG. 600 shows a flowchart of a method 600 for creating a database entry including a shieldable column according to an embodiment. Method 600 can be executed at a DBMS set up in an enclave, which enclave is, for example, enclave 202 as discussed above and shown in Figures 2 to 4 FIG. The user of the DBMS can create a database entry. At 602, the user creating the database entry can be recorded. This can be based on, for example, the login information or status of the user creating the database. The user recorded at 602 can be stored, for example, as the owner field 210 of the encrypted column directory 206, as shown in Figures 2 to 4 FIG. and described above. At 604, the user can identify a data column as a shieldable column, for example, by selection in an input interface provided by the DBMS. The identification of the shieldable column received at 604 can be stored. In an embodiment, the identification of the shieldable column can be recorded, for example, in the column identifier field 208 of the encrypted column directory 206, as described above and shown in Figures 2 to 4As shown. One or more approved viewers can be defined at 606. An approved viewer can be an approved viewer of the content of a maskable column or any identifier of an approved viewer category. At 606, a user can define an approved viewer, for example, through the user interface of the DBMS. The approved viewer defined at 606 can be stored in the DBMS. In an embodiment, the approved viewer can be stored in the approved viewer field 212 of the encrypted column directory 206. Optionally, creating a database entry with a maskable column according to method 600 can further include setting the security level 608 of the maskable column. The security level can define what data is returned when a non-approved viewer requests statistical data of the maskable column. At 608, the security level can be set by, for example, a user defining one or more rules or selecting a set of preset rules through the user interface of the DBMS. The security level can also be stored in the DBMS. In an embodiment, the security level set at 608 can be stored in the encrypted column directory 206, for example, stored in the security level field 214, as discussed above and in Figures 2 - 4 As shown.
[0063] Figure 7 FIG. shows a flowchart of a method 700 for accessing statistical data of a database according to an embodiment. Method 700 can be executed at a DBMS set up in an enclave, which is an enclave 202 such as discussed above and in Figures 2 to 4 As shown. Method 700 includes receiving a request for statistical data at 702. The request can come from any suitable source, such as the request source 300 or the second request source 400 described above and in Figure 3 and Figure 4 As shown. The request received at 702 can be processed in the DBMS by any suitable software, for example, a parser, such as the parser 302 described above and in Figure 3 and Figure 4 As shown. Processing the request can include comparing the source of the request received at 702 with the permitted viewers of the maskable column involved in the request received at 702. When, according to the comparison made at 704, the source of the request is a permitted viewer, the method can continue to determine the visibility level of the statistical data as fully visible at 708. When, according to the comparison made at 704, the source of the request is not a permitted viewer, method 700 can optionally continue to refer to the security level at 706. The security level referred to at 706 can be, for example, according to Figure 5The visibility level of the statistical data is defined by the security levels shown and described above. In the embodiment with reference to the security level at 706, when, according to the comparison at 704, the source of the request received at 702 is not an authorized viewer, the visibility level can be determined at 708 according to the security level. In an embodiment, when the reference to the security level at 706 is omitted from method 700, when, according to the comparison at 704, the source of the request received at 702 is not an authorized viewer, the visibility level can be determined at 708 according to default rules, such as completely shielding the data provided in response to such a request. At 710, the statistical data is provided in response to the request according to the determined visibility. In the case where the statistical data is determined to have a fully visible visibility level, the statistical data provided at 710 is unshielded, for example, provided as a plain text file. In the case where the statistical data is determined to have a partially or fully shielded visibility level, at least some of the statistical data is provided in a shielded format, such as being omitted, scrambled, encrypted, etc.
[0064] 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, programmable processors, computers, or multiple processors or computers. In addition to the hardware, the apparatus can include code that creates an execution environment for the computer programs discussed, for example, code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.
[0065] A computer program (also known 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 stored in a markup language document), stored in a single file dedicated to the program in question, or stored in multiple cooperating files (e.g., files that hold 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.
[0066] The processes and logical flows described in this document can be performed 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 performed 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.
[0067] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and 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 essential elements of a computer are a processor for executing the 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, e.g., magnetic disks, magneto-optical disks, or optical disks, or operatively coupled to one or more mass storage devices for receiving data therefrom or transferring 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 by way of example semiconductor memory devices, such as erasable programmable read only memory, electrically erasable programmable read only memory, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and compact disk read only memory and digital video disk read only memory disks. The processor and the memory can be supplemented by, or incorporated in, dedicated logic circuitry.
[0068] It should be understood that various features, variations, and multiple different embodiments have been shown and described in detail. 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 understood by those skilled in the art based on the complete disclosure presented at the time of filing.
[0069] Aspect:
[0070] It should be understood that any one of Aspects 1 to 12 can be combined with any one of Aspects 13 to 16 or 17 to 20. It should be understood that any one of Aspects 13 to 16 can be combined with any one of Aspects 17 to 20.
[0071] Aspect 1. A method of operating a database, comprising: Receiving, at a parser of a database management system (DBMS), a request for database statistics regarding database table columns from a source, wherein the DBMS is in a trusted execution environment; Determining a visibility level of database statistics regarding database table columns to the source based on a comparison of the source with a licensed viewer of the database statistics; and Providing the requested database statistics to the source, wherein the database statistics provided to the source are based on the visibility level of the database statistics to the source.
[0072] Aspect 2. The method according to Aspect 1, wherein the database statistics are frequency data of entries for database table columns.
[0073] Aspect 3. The method according to Aspect 2, wherein the database table column has a security level, and wherein the frequency data provided to the source is further based on the security level.
[0074] Aspect 4. The method according to Aspect 3, wherein when the source is not a licensed viewer and the security level is a low security level, the frequency data provided to the source based on the security level includes numerical frequency data with plaintext values and column data with plaintext values.
[0075] Aspect 5. The method according to any one of Aspects 3 to 4, wherein when the source is not an authorized viewer and the security level is medium security level, the frequency data provided to the source based on the security level includes digital frequency data with a plaintext value and column data with a masked value.
[0076] Aspect 6. The method according to any one of Aspects 3 to 5, wherein when the source is not an authorized viewer and the security level is high security level, the frequency data provided to the source based on the security level includes digital frequency data with a masked value and column data with a masked value.
[0077] Aspect 7. The method according to Aspect 1, wherein the database statistical information is histogram data of entries for a database table column.
[0078] Aspect 8. The method according to Aspect 7, wherein the database table column has a security level, and wherein the characteristics of the histogram data provided to the source are also based on the security level.
[0079] Aspect 9. The method according to Aspect 8, wherein when the source is not an authorized viewer and the security level is low security level, the histogram data provided to the source based on the security level includes digital y-axis data with a plaintext value and x-axis value data with a plaintext value.
[0080] Aspect 10. The method according to any one of Aspects 8 to 9, wherein when the source is not an authorized viewer and the security level is medium security level, the histogram data provided to the source based on the security level includes digital y-axis data with a plaintext value and x-axis value data with a masked value.
[0081] Aspect 11. The method according to any one of Aspects 8 to 10, wherein when the source is not an authorized viewer and the security level is high security level, the histogram data provided to the source based on the security level includes digital y-axis data with a masked value and x-axis value data with a masked value.
[0082] Aspect 12. The method according to any one of Aspects 1 to 11, further comprising generating a database table column within the DBMS, the database table column including a column identifier for the database table column, an authorized viewer for the database table column, and a security level of the database table column.
[0083] Aspect 13. A database management system (DBMS), wherein the DBMS is located within a trusted execution environment, and the DBMS includes: A database table column; A parser configured to: Receive a request for database statistical information regarding a database table column from a source; and Determine a visibility level of database statistics for a database table column with respect to a source based on a comparison of the source and the licensed viewers of the database statistics; and A runtime environment configured to provide the requested database statistics to the source, wherein the database statistics provided to the source are based on the visibility level of the database statistics with respect to the source.
[0084] Aspect 14. The DBMS according to aspect 13, wherein the database table column includes a column identifier for the database table column, licensed viewers for the database table column, and a security level of the database table column, and the database statistics provided to the source are further based on the security level.
[0085] Aspect 15. The DBMS according to any one of aspects 13 to 14, wherein the database statistics are frequency data for the database table column.
[0086] Aspect 16. The DBMS according to any one of aspects 13 to 14, wherein the database statistics are frequency data for the database table column.
[0087] Aspect 17. A non-transitory computer-readable medium storing computer-executable instructions that, when executed, cause one or more processors to perform operations including: Provide a database management system (DBMS) in a trusted execution environment; Receive, at a parser of the DBMS, a request for database statistics regarding a database table column from a source; Determine a visibility level of database statistics for the database table column with respect to the source based on a comparison of the source and the licensed viewers of the database statistics; and Provide the requested database statistics to the source, wherein the database statistics provided to the source are based on the visibility level of the database statistics with respect to the source.
[0088] Aspect 18. The non-transitory computer-readable medium according to aspect 17, wherein the database table column further includes a security level, and the database statistics provided to the source are further based on the security level.
[0089] Aspect 19. The non-transitory computer-readable medium according to any one of aspects 17 to 18, wherein the database statistics are frequency data for the database table column.
[0090] Aspect 20. The non-transitory computer-readable medium according to any one of aspects 17 to 18, wherein the database statistics are histogram data for the database table column.
[0091] 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" are intended to include the plural forms as well. 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.
[0092] Regarding the foregoing description, it should be understood that changes may be made in the details, particularly in the construction materials employed and the shape, dimensions, 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 method for operating a database, comprising: Receiving, at a parser of a database management system (DBMS), a request from a source for database statistics regarding a database table column, wherein the DBMS is in a trusted execution environment; Determining a visibility level of the database statistics regarding the database table column for the source based on a comparison of the source with a licensed viewer of the database statistics; and Providing the requested database statistics to the source, wherein the database statistics provided to the source are based on the visibility level of the database statistics for the source.
2. The method according to claim 1, wherein, The database statistics are frequency data of entries for the database table column.
3. The method according to claim 2, wherein The database table column has a security level, and wherein the frequency data provided to the source is further based on the security level.
4. The method according to claim 3, wherein, When the source is not a licensed viewer and the security level is a low security level, the frequency data provided to the source based on the security level includes numerical frequency data with plaintext values and column data with plaintext values.
5. The method according to claim 3, wherein When the source is not a licensed viewer and the security level is a medium security level, the frequency data provided to the source based on the security level includes numerical frequency data with plaintext values and column data with masked values.
6. The method according to claim 3, wherein When the source is not a licensed viewer and the security level is a high security level, the frequency data provided to the source based on the security level includes numerical frequency data with masked values and column data with masked values.
7. The method according to claim 1, wherein, The database statistics are histogram data of entries for the database table column.
8. The method according to claim 7, wherein, The database table column has a security level, and wherein characteristics of the histogram data provided to the source are further based on the security level.
9. The method according to claim 8, wherein, When the source is not a licensed viewer and the security level is a low security level, the histogram data provided to the source based on the security level includes numerical y-axis data with plaintext values and x-axis value data with plaintext values.
10. The method according to claim 8, wherein, When the source is not a licensed viewer and the security level is a medium security level, the histogram data provided to the source based on the security level includes numerical y-axis data with plaintext values and x-axis value data with masked values.
11. The method according to claim 8, wherein, When the source is not a licensed viewer and the security level is a high security level, the histogram data provided to the source based on the security level includes numerical y-axis data with masked values and x-axis value data with masked values.
12. The method according to claim 1 further comprises: Generating, within the DBMS, the database table column, the database table column including a column identifier for the database table column, a licensed viewer for the database table column, and a security level of the database table column.
13. A database management system DBMS, wherein, The DBMS is located within a trusted execution environment, and the DBMS includes: Database table columns; A parser configured to: Receive, from a source, a request for database statistics regarding a database table column; and Determining a visibility level of the database statistics for the database table column with respect to the source based on a comparison of the source with the licensed viewers of the database statistics; and A runtime environment configured to provide the requested database statistics to the source, wherein the database statistics provided to the source are based on the visibility level of the database statistics with respect to the source.
14. The DBMS according to claim 13, wherein, The database table column includes a column identifier for the database table column, licensed viewers of the database table column, and a security level of the database table column, and the database statistics provided to the source are further based on the security level.
15. The DBMS according to claim 13, wherein, The database statistics are frequency data for the database table column.
16. The DBMS according to claim 13, wherein, The database statistics are histogram data for the database table column.
17. A non-transitory computer-readable medium having computer-executable instructions stored thereon that, when executed, cause one or more processors to perform operations including: Providing a database management system DBMS in a trusted execution environment; Receiving, at a parser of the DBMS, a request from a source for database statistics regarding a database table column; Determining a visibility level of the database statistics for the database table column with respect to the source based on a comparison of the source with the licensed viewers of the database statistics; And Providing the requested database statistics to the source, wherein the database statistics provided to the source are based on the visibility level of the database statistics with respect to the source.
18. The non-transitory computer-readable medium according to claim 17, wherein, The database table column further includes a security level, and the database statistics provided to the source are further based on the security level.
19. The non-transitory computer-readable medium according to claim 17, wherein, The database statistics are frequency data for the database table column.
20. The non-transitory computer-readable medium according to claim 17, wherein, The database statistics are histogram data for the database table column.