The present application is related to the following applications that are concurrently filed and the entire contents of which are hereby incorporated by reference as if fully set forth herein. The related concurrently filed applications are: DATA MIGRATION by inventors, Brian Metzger, Bruce Sandell, Stephen Mauldin, and Jorge Chang filed on Sep. 26, 2005; and KEY ROTATION by inventors, Brian Metzger, Bruce Sandell, Stephen Mauldin and Jorge Chang filed on Sep.26, 2005.
The present invention is directed to data security, and more specifically to protecting sensitive data that resides in a database and allowing authenticated application programs to access the sensitive data in a manner that is transparent to the application programs and the database.
It cannot be gainsaid that confidential information, such as credit card numbers, social security numbers, patient records, insurance data, etc., need to be protected. Although enterprises have instituted procedures for protecting such sensitive data when such data is in transit, more often than not, such data is stored in unencrypted format (“clear text” or “plain text”). For example, data is often stored as clear text in databases. The clear text is visible to attackers and disgruntled employees who can then compromise the data and/or use the data illegitimately. Further, not only is data security a feature that is highly desired by customers but it is also needed to comply with certain data security regulations. In order to adequately protect data, organizations need to institute procedures to protect data at all times including when the data is in storage, when the data is in transit, and when the data is being used.
It is also desirable to have the ability to selectively encrypt certain database tables in a given database and/or certain columns of the database tables rather than encrypting all of the columns of all of the database tables. However, to provide encryption at a granular level, such as at the column level for a database table, requires extensive changes to the application programs that wish to access the encrypted data in the given database. Such an approach is inconvenient and would require considerable time and effort to implement such a solution.
According to certain embodiments, an unsecured database system is converted to a secure system by providing mechanisms for converting existing data that resides in the relational database into encrypted format. Further, according to certain embodiments, a mechanism is provided to allow for granular protection of sensitive data in the database. In other words, certain tables in the database can be selected for encryption. If desired, certain columns in a given database table can be selected for encryption, rather than encrypting the entire database table. Such granular protection is implemented with minimal impact to the database and the application programs that access data in the database. Authorized application programs can seamlessly access encrypted data with little or no change to the application program.
According to certain embodiments, a mechanism is provided to allow application programs that are external to the relational database to access the sensitive data in the database in a seamless fashion. To explain, the application programs should be allowed to use existing query statements that are normally used for accessing non-encrypted data without having to modify such statements for accessing encrypted data in the relational database. In other words, the application programs can use the same query statements that were used for accessing the sensitive data in the database before the sensitive data was encrypted.
According to certain embodiments a mechanism is provided for allowing the management of a seamless interaction between the relational database and the one or more mechanisms for: 1) encrypting and decrypting data on demand from inside the relational database, 2) migrating data from plaintext columns to encrypted columns, 3) automating subsequent encrypt and decrypt operations, 4) authenticating users so that only authorized users are able to access sensitive data.
According to some embodiments, when an authorized application program makes requests to access sensitive data that is already encrypted in a given source database table, a view of the source table is instantiated using metadata tables. Further, the requested sensitive data is decrypted and such a view is populated with the decrypted sensitive data. Any actions executed by the requesting application program on the view are captured. In response to the captured actions, new actions are automatically executed on the corresponding source table as if the requesting application was acting directly on the corresponding source table.
According to certain embodiments, the database provider, such as database provider 110, is a PL/SQL (Procedural Language/Structured Query Language) layer that comprises several functions for exposing features of a given cryptography provider to a given relational database. Such functions include but are not limited to: 1) function for setting system properties that the cryptography provider may need such as setting the location of client certificate key store and password, 2) function for setting the cryptography server user name and password for a specific user of the relational database, 3) optional function for encrypting a string and returning the data as a Base64 encoded string, 4) optional function for decrypting Base64 encoded string and returning the original unencrypted string, 5) optional function for encrypting a number and returning the data as a Base64 encoded string, 6) optional function for decrypting Base64 encoded string and returning the original unencrypted number, 7) optional function for encrypting a string and returning the data as a raw binary, 8) function for decrypting a raw binary and returning the original unencrypted string, 9) function for encrypting a number and returning the data as a raw binary, 10) function for decrypting a raw binary and returning the original unencrypted number, 11) function for encrypting a string and returning the data as bit data, 12) function for decrypting bit data and returning the original unencrypted string, 13) function for encrypting a number and returning the data as bit data, and 14) function for decrypting bit data and returning the original unencrypted number.
According to certain embodiments, the Cryptography server, such as the NAE server, listens for client connections and manages cryptography operations and encryption key management operations. The cryptography server allows a user or cryptography server client to perform cryptography operations including operations associated with encryption keys, authentication, encryption and decryption of data, create digital signatures, generation and verification of Message Authentication Code (MAC).
The cryptography server allows a cryptography server client to perform cryptography operations through the cryptography provider. The cryptography provider is the API to the cryptography server, according to certain embodiments. It is the cryptography provider that communicates with the cryptography server to request for cryptography services.
At block 204, source table “CUSTOMER” is renamed so that a view can be created later with the same name, “CUSTOMER”. Assume that the source table “CUSTOMER” is renamed to “CUSTOMER_ENC” as shown in Table 2, herein.
However, data in column CC_NUM in the renamed source table “CUSTOMER_ENC” as shown in Table 2 has not yet changed but will change in a manner as described at block 210.
At block 206, a temporary table is created and the sensitive data from column CC_NUM from the renamed source table, CUSTOMER_ENC, is exported to the temporary table. After exporting the sensitive data to the temporary table as described at block 206, at block 208, the data in column CC_NUM in CUSTOMER_ENC are set to null to avoid any data conversion that might arise when changing the data type at a later step. An example of temporary table is shown in TABLE 3 as CUSTOMER_TEMP, herein.
At block 210, the data type and column size of column CC_NUM are modified to accommodate encrypted data because encrypted data is predictably larger than clear text data. As a non-limiting example, the encrypted data can be stored in Base64 encoded format or as binary data. After the data type and column size of column CC_NUM have been modified, and before the sensitive data from temporary table, CUSTOMER_TEMP, is imported back into CUSTOMER_ENC, at block 212, the cryptography provider sends the sensitive data from the temporary table to cryptography server where the sensitive data is encrypted.
At block 214, the cryptography server returns the encrypted sensitive data to the cryptography provider. The cryptography provider inserts the encrypted sensitive data into column CC_Num of the renamed source table, CUSTOMER_ENC. The source table that includes encrypted data may appear as shown in Table 4, herein.
At block 302 of
However, if it is determined that the requested data is sensitive data, then at block 308, the user is authenticated to the cryptography server through the cryptography provider. In a non-limiting example of authentication, the user is asked for a valid user name and password. In another non-limiting example of authentication, in addition to being asked for a valid user name and password, the user may be asked for a client certificate. In another non-limiting example, the user's credentials are stored in the relational database, and thus can be retrieved from the database.
At block 310, it is determined if the user is successfully authenticated. If it is determined that the user is not successfully authenticated, then at block 312, the user's request to access data is denied.
However, it is determined that the user is successfully authenticated, then at block 314, the database provider automatically instantiates a view of the database table that contains the requested sensitive data and populates the instantiated view with the decrypted form of the requested sensitive data. According to certain embodiments, such a view is instantiated using metadata tables. At block 316, the populated instantiated view is revealed to the user. The user can then interact with the revealed view. Returning to the example described in reference to
At block 402 in
At block 404, in response to the authorized user's attempt to execute the insert statement on the view, one or more triggers cause the user's insert statement to be trapped. At block 406, a request is made to the NAE server for encryption to be performed so that a new insert statement can be generated based on the insert values of the trapped insert statement. In other words, the NAE server performs encryption on the insert values. At block 408, the new insert statement is executed on the corresponding source database table corresponding to the populated instantiated view.
At block 502 in
At block 504, in response to the authorized user's attempt to execute the update statement on the view, one or more triggers cause the user's update statement to be trapped. At block 506, a new update statement is generated based on the update values of the trapped update statement. At block 408, the new update statement is executed on the original database table corresponding to the populated instantiated view.
In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.