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: T
The present invention is directed to data security, and more specifically to protecting sensitive data that resides in a database and providing a mechanism for automating the conversion of the database to a secure database with little or no impact on the resources of the database during the conversion.
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.
However, in order to convert existing databases into a secure system, vast computing resources are required because large volumes of data need to be converted. It is desirable to make the conversion so as to not drain the computing and storage resources of the target relational database. It is also desirable to make the conversion as transparent and convenient as possible for the administrator of the target database.
According to certain embodiments, an unsecured relational database system is converted to a secure system by providing mechanisms for converting existing data that resides in the relational database into encrypted format with minimal impact to the resources of the relational database.
According to certain embodiments, a mechanism that is used for migrating target data for encryption from the target database includes the following functionality: 1) identify which tables a user is authorized to modify, 2) determine which columns, in the identified tables, that the user is authorized to encrypt, 3) accept input parameters for specifying the characteristics of the desired encryption, 4) modify or create column lengths and data types as required for each column that is targeted for encryption, 5) encrypt clear text data that is present in each column that is targeted for encryption, and 6) provide an “undo” functionality for restoring an encrypted column to its original size and data type as well as restore the target data to its unencrypted form.
According to certain embodiments, a mechanism is provided to allow the encryption of the target data to occur on a device that is separate from the relational database so as to not drain the computing and storage resources of the relational database. Such a mechanism can include a management console for managing the migration of data from the target database to the encryption server for processing.
According to certain embodiments, the database data that is targeted for encryption is performed on a specialized piece of hardware that is designed to rapidly perform data encryption on large volumes of data from the relational database that is targeted for conversion to a secure system. Further, such a specialized piece of hardware is equipped with its own CPU and processing power in order to offload the database server that is associated with the target relational database.
According to certain embodiments, a mechanism that is separate from the relational database and that is used for encrypting target data stores cryptographic keys in a highly secure manner so as to be inaccessible to non-authenticated processes.
According to certain embodiments, a mechanism that is separate from the target relational database issues a select statement to retrieve target data from the target relational database. Such a mechanism then performs multithreaded, hardware level encryption on the target data. After the target data is encrypted, the mechanism issues an update statement to copy the encrypted data back into the target relational database.
Relational database 108 includes, among other components, a plurality of data tables such as table 110 and a plurality of metadata tables such as metadata table 112. The metadata tables in the relational database can be used for storing information that includes but is not limited to 1) each authorized user's access rights with respect to database tables and columns managed by the relational database, and 2) database table and column schema, 3) information on encryption methods, and 4) information on properties of tables and columns that are selected for encryption from the target database. The cryptography server retrieves target data from the selected target relational database. The cryptography server then performs encryption on the target data. According to certain embodiments, the cryptography server then performs multithreaded, hardware level encryption on the target data.
A user such as a security administrator or database administrator can use a client computer to manage the encryption process of data in the relational database by accessing a data management console associated with the cryptography server. According to certain embodiments, the data management console allows the user to login to a desired database server and communicate with the database. In certain other embodiments, the desired relational database may include a database provider and cryptography provider. According to certain embodiments, the database provider is a computer-implemented functionality of the relational database server and can communicate with the cryptography server. The cryptography provider communicates with the cryptography server to request for cryptography services. The cryptography provider is the API to the cryptography server, according to certain embodiments.
According to certain embodiments, the cryptography server, such as the NAE server, 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 the encryption and decryption of data, encryption keys, authentication, creation of digital signatures, generation and verification of Message Authentication Code (MAC).
According to certain embodiments, the cryptography server includes a data migration tool that includes the following functionality: 1) identify which tables a user is authorized to modify, 2) determine which columns, in the identified tables, that the user is authorized to encrypt, 3) accept input parameters for specifying the characteristics of the desired encryption, 4) modify or create column lengths and data types as required for each column that is targeted for encryption, 5) encrypt clear text data that is present in each column that is targeted for encryption, and 6) provide an “undo” functionality for restoring an encrypted column to its original size and data type as well as restore the target data to its unencrypted form.
At block 202 of
When the user's login information is submitted, an attempt to connect to the target database server is initiated. According to certain embodiments, if the connection attempt is successful, the database connection information is stored on the cryptography server. Such database connection information can be collected and stored for each type of database so that during future login attempts, the user can be presented with a login screen that requires a minimum amount of data entry for a selected target database.
If the connection attempt to connect with to the target database is unsuccessful, then the user may be presented with an error message and is allowed to reenter login information.
At block 204 of
At block 206 of
The accessible list of columns is returned to the management console for presenting to the user. According to certain embodiments, in addition to determining the accessible list of columns, the database metadata tables and the encryption information stored on the cryptography server can be queried to determine certain information on the columns that may be useful to the user. The information on the columns that may be useful to the user is herein referred to as column information. The column information can help the user decide whether to accept or reject the column as a candidate for encryption.
The column information is returned to the management console for presenting to the user. Such column information may vary from implementation to implementation. Some non-limiting examples of column information relate to: 1) whether a column has a data type that is supported (the user is advised to reject columns with non-supported data types as candidates for encryption), 2) whether a column is used as a primary key (the user is informed that a primary key column may be encrypted if such a column is not referenced as a foreign key, either explicitly or implicitly), 3) whether a column is used as a foreign key (the user is advised to reject columns that are used as foreign keys as candidates for encryption), 4) whether a column is used in an index (the user is advised that the sort order of encrypted data will not be consistent with the sort order of clear text data), 5) whether a column has a default value assigned to it (the user is advised to reject columns that have default value assigned to them as candidates for encryption), 6) whether a column has a check constraint (the user is advised to reject columns that have check constraints as candidates for encryption), 7) whether a column is referenced in any triggers on the database table in which the column resides (the user is advised to review the trigger(s) to see if the trigger(s) will function as expected), and 8) whether a column is in encrypted format (the user is advised to reject columns that are already encrypted as candidates for encryption). One or more of the above non-limiting examples of column information may involve manual checks, according to certain embodiments.
At block 210 of
At block 214 of
At block 304, data from the columns that are selected for encryption from the base table referenced in block 302 are loaded into a temporary table, along with the identity referenced in block 302 and an incremented row counter. According to certain embodiments, the incremented row counter can be used to support user-specified batch sizes for processing. The loaded data in the temporary table is then encrypted by the cryptography server using the selected encryption method, mode, initialization vector and padding, if applicable.
At block 306, the data values corresponding to the columns selected for encryption in the base table referenced in block 302 are set to NULL. The data values are set to NULL in order to modify the corresponding column size and datatype.
At block 308, the column size and datatype of the columns selected for encryption are modified in order to support the selected encryption algorithm and padding.
At block 310, the base table referenced in block 302 is updated with the encrypted version of the data from the temporary table referenced in block 304 by calling one of the TSQL encryption procedures.
At block 312, the temporary table referenced in block 304 is dropped after the data encryption process is complete and validated. At block 314, an “undo” functionality is provided for reversing the encryption process as described with reference to
At block 406, the column values of the original unencrypted data are set to NULL. At block 408, the base table referenced in block 402 is renamed in order to create a view of the base table with the same original name. At block 410, a view is created on the base table referenced in block 408 with the same name as the base table before the base table was renamed. At block 412, an “undo” functionality is provided for reversing the encryption process as described with reference to
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.