Patent Description:
Many users use database systems to store sensitive data. Modern database systems have extensive security capabilities to protect user data from theft, insider threat, and unauthorized access. These controls are all focused around protecting the user data that is managed by the database systems.

Unfortunately, the user data that is managed by a database system may not be the only sensitive information. In particular, there are situations when analysts or applications want privacy when querying the database, because their interest in a situation, company, customer, person or device etc. is highly sensitive. In these cases, the question/query may even be more sensitive than the answer/data.

For example, consider the query:
Select FirstName, LastName
From Person P
Where P. SSN = '<NUM>-<NUM>-<NUM>';.

This query clearly shows an analyst is looking for the first and last name of the person with social security number "<NUM>-<NUM>-<NUM>". This query may be issued, for example, as part of an investigation. It may be critical that the specific people targeted by the investigation remain secret.

The following queries are additional examples of queries where the query itself may reveal information that is confidential:.

The following query looks up a Credit Card for a charge:
Select FirstName, LastName, ExpDate,cvc
From Customer C
Where C. Card_type = 'AMEX'
and C. Card# = '<NUM><NUM><NUM>'
and C. Card_Exp > Sysdate;.

The following query expresses interest in people with Financial Infractions over $<NUM>:
Select FirstName, LastName
From Person P, Per_of_interest POI
Where P. event_type = `Financial Infraction'
and P. Amount > <NUM>;.

The following query reflects investigative interest in people with names similar to John Smith:
Select SSN, FirstName, LastName
From Person
Where P. Lastname = soundex('SMITH')
and P. Firstname = soundex('JOHN')
and P. State in ('VA' , `MD','CA','NY', `MA')
and P. last_login_date > sysdate - <NUM>;.

The follow query may indicate a reduction in force for people with large sales exceeding an expense threshold:
<IMG>.

Even when there is no data that satisfies a sensitive query, such as those set forth above, the query text is very sensitive and visible through (a) a shared cache (e.g. the Shared Global Area (SGA) of Oracle database systems) which stores the clear text version of the queries that have been issued to the database system), (b) tracing/logging tools, (c) SQL_Capture tools, and (d) audit tools. The shared cache is a shared memory area where a database system caches the SQL statements that it has received. Typically, anybody with the appropriate privileges can query the SGA and see the clear text versions of those cached SQL statements.

In conventional database systems, there is no way to hide a sensitive query. Consequently, instead of issuing sensitive queries that specifically target desired information, analysts instead ask very broad non-specific queries, hoping that the specific information they desire is somewhere within the results of the broader query. The results of such broad queries are typically much larger than the desired information, and must be further extracted or refined privately by the end user so as to not expose the true intent of the query. This strategy adds much more overhead to the system, complexity to the process, and latency to the answer, simply to try and maintain some semblance of privacy and to try to avoid the exposure the true interest.

<CIT> discloses a technique for providing increased role and security enforcement for database log files. A user composes and submits a query for execution. If secure logging is enabled and the executed query includes a logical field with logging metadata indicating that the use of that field should be encrypted in a log event record, or if secure logging is turned on globally, then a runtime component encrypts a query component of the query, and further encrypts query result data.

The publication "Cloudera Enterprise <NUM>. x", section "Log and Query Redactions", describes a software component called "Cloudera Manager", which provides a configurable log and query redaction feature that lets a user redact sensitive data as it is being written to log files, to prevent leakage of sensitive data. Regular expressions are used to target data for redaction. Segments of data that match a regular expression are redacted by replacing them with a replace string.

The dependent claims concern optional elements of some embodiments of the present invention.

Techniques are provided for selectively or completely redacting the text of the database commands submitted to a database system. The database server receives the clear text version of the commands, parses the commands, and generates an execution plan, as normal. However, prior to providing the text of the commands to any location that is externally visible, the database server determines whether the command qualifies as "sensitive". If the command qualifies as sensitive, then a redacted version of the command is generated. In the case of selective redaction, portions of the redacted version remain in clear text, while selected portions are replaced with encrypted text. In the case of total redaction, the entire command is replaced with encrypted text.

Techniques are described hereafter for encrypting sensitive query text and bind values with an authorized user/session Query Encryption Key ("QEK"). With total command redaction, SQL text and bind values remain encrypted at all times other than parse and execution time. Audit events and system logging occurs as normal, except that query text and bind values will be encrypted when written. In one embodiment, when a log includes a redacted command, an identifier of the QEK (a "QEK ID") is also recorded in the log. Thus, the encrypted data of a redacted command can only be unencrypted with the appropriate QEK, and which QEK is appropriate may be determined by the QEK ID in the log.

<FIG> is a flowchart illustrating general steps for database command redaction, according to an embodiment. At step <NUM>, the database server receives a database command. At step <NUM>, the database server parses and executes the command based on the clear text version of the database command. At step <NUM>, the database server determines whether the database command should be selectively or totally redacted to external sources.

If, at step <NUM>, it is determined that the command is not to be selectively or totally redacted, then control proceeds to step <NUM> and the clear text version of the command is made available to the external sources. Thus, at step <NUM>, the clear text version of the command may be stored in the Shared Global Area of the computing device on which the database server is executing, written to an audit log, etc..

On the other hand, if it is determined at step <NUM> that the command is to be selectively or totally redacted, then control proceeds to step <NUM> and a redacted version of the command is generated. At step <NUM>, the redacted version of the command is made available to the external sources. The steps of determining whether to redact a command, and generating a redacted command shall be described in greater detail hereafter.

According to an embodiment, not all database commands received by a database system are redacted. Thus, as illustrated in step <NUM> of <FIG>, the database server must determine whether a database command qualifies for redaction. In one embodiment, a database command is not redacted unless the database server receives an indication that redaction should be performed.

A database server that employs the command redaction techniques described herein may support various levels of redaction indicators. For example, in one embodiment, redaction may be indicated by:.

In addition, command redaction may be based on what data is targeted by a database command. Thus, a database server may be configured to redact database commands that:.

Command redaction may also be based on other criteria. For example, command redaction may be automatically performed for all queries that are submitted during a certain time period, such as on particular days or during particular hours. As another example, command redaction may be automatically performed based on the number of rows returned by a query. For example, command redaction may be automatically performed when a query produces a single result row, or when the number of rows returned by the query is less than a threshold number, or is less than a certain percentage of all rows in the targeted table.

These are merely examples of the various ways redaction may be indicated and/or triggered. The techniques described herein are not limited to any particular manner of indicating that query redaction should be performed.

In one embodiment, certain users are granted a "redacted_session" role, which is reflected in their user accounts. Users with such a role may initiate redacted sessions. During a redacted session, all database commands (or a subset of commands, such as queries) are redacted using a user-specific or session-specific QEK. In the case of a session-specific QEK, the user may set a QEK with a password, or request that the database server automatically generate a QEK for the session. The QEK may then be stored in a secure location within the database system, such as the user's "wallet" or other secure storage.

The following is an example of interactions with a database system to authorize a user to use database command redaction. A DBA or User Account Manager grants the Redacted Session role to a user by submitting the following database command:.

The Key Manager or a User with the Redacted command role creates and sets a query encryption key for a user. Multiple QEKs may be specified for the same user. When a user has multiple QEKs, the QEKs may be used in a round-robin fashion, where the QEK for the user alternates from session to session, or from command to command within a session.

Two query keys can be created for user1, for example, by submitting the following database commands:.

After the keys are created for user1, a current key may be established for user1 by submitting one of the following database commands:.

Once the database server determines that a command qualifies for redaction, a redacted version of the command is generated, as is illustrated in step <NUM> of <FIG>. According to one embodiment, the redacted version of a database command is created by replacing clear text in the command with encrypted text. The encrypted text that is used to replace a particular string of clear text is created by encrypting the particular string of clear text using a Query Encryption Key ("QEK"). For example, assume that the following query is subject to total redaction:
Select FirstName, LastName
From Person P
Where P. SSN = '<NUM>-<NUM>-<NUM>';.

Because the query is subject to total redaction, the entire text of the original query string is encrypted, which may produce the encrypted SQL text:
4DF70F835912C3EDB3EDC30E33540BA377B0B4687EF5A48E975C393314 E <NUM> AFD 1BA5F &77BOB3.

As illustrated in step <NUM> of <FIG>, the database server provides this encrypted SQL text to all external sources where the SQL text itself would normally be provided. For example, this encrypted SQL text is stored in the SGA of the database server, and is stored in all logs where the SQL itself would normally appear.

For selective redaction, the redacted version of a command is created by encrypting selected portions of the original query using a QEK. The portions that are not encrypted remain in their original clear text form. For example, assume that only the specific social security number that is targeted by the query:
Select FirstName, LastName
From Person P
Where P. SSN = '<NUM>-<NUM>-<NUM>';
is to be redacted. Under these circumstances, the redacted version of the query may be:
Select FirstName, LastName
From Person P
Where P. SSN = F&77B0B3;.

According to one embodiment, when selective redaction is performed, different parts of the database command may be encrypted using different QEKs. For example, social security numbers may be encrypted using one QEK, while phone numbers may be encrypted using a different QEK. By using different QEKs for different parts of a selectively-redacted database command, different decryption keys will be required to recover the clear text of those portions. By making different decryption keys available to different parties, one may control which information, within redacted database commands, is available to different parties.

According to one embodiment, in a situation where all queries in an entire session are to be redacted, the interactions with the database may proceed as illustrated in <FIG>. Referring to <FIG>, at step <NUM>, a database client establishes a connection to the database server, to ensure network communication is encrypted. At step <NUM>, the database system validates the user's connection to ensure that the user has been authorized with the Redacted command role. In one embodiment, the redacted command role can be enabled by default or enabled on demand by the user/application. The following commands are examples of how the session can be set to Redacted_Query and how to specify the QEK that is to be used during the session.

At step <NUM>, the database system retrieves the appropriate QEK from a secure location "keystore" in the database. The secure location may be, for example, a user-specific wallet or a key vault.

At step <NUM>, the database client submits SQL statements to the database server for execution as normal. The fact that Redacted_Command is in effect is transparent to the application, so no application changes are required.

At step <NUM>, the database server parses, validates and encrypts the text and bind values of the relevant types of database commands. For example, in a database system that applies redaction only to SELECT statements, only the text and bind variables of those statements are redacted. Other types of statements will be processed as normal.

At step <NUM>, the database server executes the statements independent of whether the SQL text and bind values are encrypted. The database system can decrypt redacted text or bind values as needed if required for execution.

As illustrated in <FIG>, the SQL Text and bind values are maintained in an encrypted state when:.

Significantly, because the encrypted SQL text in the redacted version of a command is an encryption of the SQL that it is replacing, the original clear text SQL can be reproduced from the redacted version of the command by anyone with access to the appropriate decryption key. Thus, when the following encrypted SQL is encountered in an audit log:
4DF70F835912C3EDB3EDC30E33540BA377B0B4687EF5A48E975C393314 E <NUM> AFD 1BA5F &77BOB3.

a user with the appropriate decryption key can reproduce the original SQL text:
Select FirstName, LastName
From Person P
Where P. SSN = '<NUM>-<NUM>-<NUM>';.

In the same manner, selectively redacted commands are encrypted in such a way that one having the proper decryption key can reproduce the original SQL text. For example, the following selectively redacted command:
Select FirstName, LastName
From Person P
Where P. SSN = F&77B0B3;
may be converted back to the original clear text command by applying the appropriate decryption key to the encrypted text "F&77B0B3". Doing so would reproduce the social security number specified in the original SQL command (i.e. '<NUM>-<NUM>-<NUM>').

As mentioned above, it is desirable to allow users that have the appropriate decryption key to recover the clear text version of a redacted command based on the redacted version of the query. However, to do so, it is necessary for those users to determine which decryption key is the appropriate decryption key.

According to one embodiment, to assist users to determine the appropriate decryption key to decrypt a redacted command, a "QEK identifier" is stored as part of the redacted version of the query. A QEK identifier is any data from which the QEK used to create a redacted version of a database command may be determined. For example, upon creating a QEK for a user, the database server may generate a unique identifier for the QEK. The QEK identifier for a QEK is stored in conjunction with any redacted command that includes data encrypted using the QEK. For example, in the log generated for a session whose commands are encrypted using Key1, the identifier for Key1 may be stored.

The granularity at which QEK identifiers are stored in a log may vary based on the scope at which the corresponding QEK was used. For example, when a single QEK is used to redact all commands in a session, then the QEK identifier for the QEK may be stored once for the entire log of the session. On the other hand, multiple QEKs are used within a session, then a QEK identifier may be stored in conjunction with each command the QEK was used to redact. In the case where different QEKs are used to redact different portions of the same command (e.g. one QEK used to redact social security numbers and a different QEK used to redact telephone numbers), then the corresponding QEK identifiers may be stored in association with the portions of the database command they were used to redact.

In one embodiment, instead of or in addition to having user/session-specific command redaction, a database system may support policy-based command redaction. With policy based command redaction, what is redacted is based on stored policies. The policies may be simple or complex. For example, one policy may be to redact individual social security numbers using encryption with a particular QEK. Another policy may be to encrypt the entire commands of all users who are at the vice-president level or higher during the last three weeks of every quarter.

When multiple policies call for the encryption of the same piece of information, the coarser-granularity encryption is used. For example, if one policy calls for an entire command to be encrypted using QEK1, and another policy calls for a portion of the command to be encrypted using QEK2, then the entire command is encrypted using QEK1. In an alternative embodiment, a piece of data may be encrypted multiple times. Thus, QEK2 may be used to encrypt the portion of the command to produce a selectively redacted command, and then that selectively redacted command may be encrypted using QEK1 to produce a fully-redacted command.

According to one embodiment, when a query is redacted, the database server redacts the results of the query using the same QEK as was used to redact the query. For example, assume that a user submits a query, in a redacted session, to retrieve certain rows from the database system. Assume further that all queries in the redacted session are being encrypted with Key1. Under these circumstances, Key1 is also used by the database server to encrypt the rows selected by the query prior to providing those rows back to the application that submitted the query. Once received at the application, those results may be decrypted using Key <NUM>.

According to one embodiment, upon starting a redacted session, a user may specify whether the query results are to be encrypted. If no result encryption is indicated, then the query is redacted by encrypting the query based on a QEK as described above, but the query results are returned without being encrypted using that same QEK.

In one embodiment, some or all of a user's session context with a database system may be redacted. For example, when a user submits a query or Data Manipulation Language command (DML), the database system tracks the username, IP address of client, hostname of client, client program, and time. In one embodiment, some or all of these pieces of information are redacted from audit trails, logs, etc..

The term "cloud computing" is generally used herein to describe a computing model which enables on-demand access to a shared pool of computing resources, such as computer networks, servers, software applications, and services, and which allows for rapid provisioning and release of resources with minimal management effort or service provider interaction.

A cloud computing environment (sometimes referred to as a cloud environment, or a cloud) can be implemented in a variety of different ways to best suit different requirements. For example, in a public cloud environment, the underlying computing infrastructure is owned by an organization that makes its cloud services available to other organizations or to the general public. In contrast, a private cloud environment is generally intended solely for use by, or within, a single organization. A community cloud is intended to be shared by several organizations within a community; while a hybrid cloud comprises two or more types of cloud (e.g., private, community, or public) that are bound together by data and application portability.

Generally, a cloud computing model enables some of those responsibilities which previously may have been provided by an organization's own information technology department, to instead be delivered as service layers within a cloud environment, for use by consumers (either within or external to the organization, according to the cloud's public/private nature). Depending on the particular implementation, the precise definition of components or features provided by or within each cloud service layer can vary, but common examples include: Software as a Service (SaaS), in which consumers use software applications that are running upon a cloud infrastructure, while a SaaS provider manages or controls the underlying cloud infrastructure and applications. Platform as a Service (PaaS), in which consumers can use software programming languages and development tools supported by a PaaS provider to develop, deploy, and otherwise control their own applications, while the PaaS provider manages or controls other aspects of the cloud environment (i.e., everything below the run-time execution environment). Infrastructure as a Service (IaaS), in which consumers can deploy and run arbitrary software applications, and/or provision processing, storage, networks, and other fundamental computing resources, while an IaaS provider manages or controls the underlying physical cloud infrastructure (i.e., everything below the operating system layer). Database as a Service (DEaaS) in which consumers use a database server or Database Management System that is running upon a cloud infrastructure, while a DbaaS provider manages or controls the underlying cloud infrastructure, applications, and servers, including one or more database servers.

Claim 1:
A method, executed by a database server, comprising:
receiving (<NUM>) a clear text version of a database command;
based on the clear text version, parsing, compiling and executing (<NUM>) the database command;
determining (<NUM>) that the database command qualifies as sensitive;
wherein determining (<NUM>) that the database command qualifies as sensitive includes receiving, from a user that submits the clear text version of the database command, a redacted query indication;
wherein the redacted query indication (i) is a command-specific flag indicating that only the database command qualifies as sensitive, or (ii) indicates that all database commands in a particular session qualify as sensitive;
wherein the database command is determined (<NUM>) to be sensitive based on the redacted query indication;
responsive to determining (<NUM>) that the database command qualifies as sensitive, generating (<NUM>) a redacted version of the database command;
wherein, in the redacted version of the database command, at least a portion of the database command is encrypted using a particular encryption key; and
based on the database command qualifying as sensitive, storing (<NUM>) the redacted version of the database command in a log where the clear text version would have been stored if the database command had not qualified as sensitive.