What is “server-side” encryption?
This is encryption that takes place at the server machine as opposed to the client machine, as in NEP. With server-side encryption, the encryption drivers only need to reside on the server machine where the database process resides. Encryptionizer for SQL Server and for SQL Express is a server-side encryption tool.
What is the difference between Transparent Database Encryption and Column Encryption?
Transparent database encryption and column encryption are actually two completely different methods of providing data encryption. Each has its advantages and limitations. For more information, please follow this link: Differences between transparent database and column encryption.
Why is NetLib’s Transparent Database Encryption (Whole Database) faster than Column Encryption?
It seems counter-intuitive. Why would performance when working with a wholly encrypted database be better than performance when working with just a few columns? That is because NetLib’s patented Transparent Database Encryption processing actually takes place between the SQL Server and file system layers. Since Transparent Database Encryption works at such a low level, it is very efficient. As a matter of fact, on a multi-processor machine, our clients have noted virtually no impact on performance when working with a wholly encrypted database. Since column encryption works within SQL Server itself, there is some performance impact, reported to be 5-6 percent slower accessing an encrypted column vs. a plaintext one. This performance impact is additive when accessing multiple encrypted columns at one time. As a general rule of thumb, because of the possible performance impact of column encryption, if more than 10 percent of the database needs to be encrypted, Transparent Database Encryption is recommended.
How is Encryptionizer different from other encryption tools?
Most encryption security tools are not designed to work with SQL Server or SQL Express. The few that do require a large amount of ongoing administration. Some are considerably more expensive. Generic encryption tools, such as those that encrypt an entire directory or drive, are usually suitable for small standalone systems and require the user to enter a key anytime the directory is accessed. Encryptionizer is designed for high-volume, multi-processor servers and does not require the user to enter or even know the key.
Can I use Encryptionizer to protect a database from the DBA?
In many cases, yes. This is often important to developers distributing an MSSQL Server or SQL Express-based application. They want to ensure that the end user can only access the database through the supplied application, not through SQL Management Studio or a query window. Just changing the SA password is not enough! The end user can easily foil this. For example, they can: copy the database to a fresh install of SQL Express or SQL Server; or restore the backup to a different instance of SQL Server; or even overwrite your Master database with one from a fresh install of SQL Server or SQL Express. If your application uses a dedicated instance of SQL, it is possible to lockout Sysadmins from accessing encrypted data. See this article for more information.
Who needs to know the encryption key(s)?
Only the person who originally encrypts the database needs to know the key(s). This is usually the DBA or an administrator of some kind. Our “Split Knowledge Protocol” allows you to split a key among two or more people so that no single person knows the entire key. One optional feature allows you to ask Encryptionizer to generate a random key. If you are distributing a SQL Server or SQL Express-based application you can select a key when you build your application, or when your application is installed. Alternatively, you can let the customer choose the key(s).
Where are the data keys stored?
Data keys are stored with a variety of methods, and we are constantly adding new methods. The primary methods are:
- Keys can be stored in a strongly encrypted file (called a profile) on the local drive.
- Keys can be stored in a profile on a floppy disk, CD, or USB key. The authorized user must insert the floppy disk, CD, or USB key to start SQL Server. (The disk can be removed once the application starts).
- Keys can be stored in a profile on a remote machine (refe rred to as a proxy location). If the proxy machine is not found, SQL Sever cannot be started.
- Key(s) can be embedded into the application with an API call.
- A designated person can enter the key manually when SQL Server is started. This is suitable only where an authorized starter will always be on hand.
What editions of SQL Server do you support?
We work on all editions of SQL server from SQL Express to Enterprise.
Encryptionizer is tested with major released service packs for SQL Server. It is not specifically tested with Hotfixes or Cumulative Updates. If you must apply a Hotfix or Cumulative Update, we recommend as Microsoft does to test in a test or development environment prior to deploying to your production servers.
Does Encryptionizer work on clustered servers?
Yes! Encryptionizer for SQL Server works with clustered servers, both active/active and active/passive on Windows 2003 and up. Encryptionizer must be installed independently on each server. The User Guide includes detailed instructions for installation on a cluster.
Can I split keys for added security?
Encryptionizer has a feature whereby two different people to are able to enter a portion of the key without allowing each to see the other portion.
What documentation is included?
All documentation is included in electronic form. A Tutorial Guide will give you a quick overview to getting Encryptionizer up and running quickly with the most common scenarios. A more detailed User Guide is provided with detailed explanations of all features available. The Developer Version for Application Developers distributing Encryptionizer bundled with their applications receive instructions for constructing their installation scripts, as well as detailed documentation on use of CLI’s with sample scripts to configure Encryptionizer as part of their bundle.
What encryption algorithms and key lengths do you use?
Encryptionizer is standardized on the AES algorithm. Depending on use, we have several formulations of the AES algorithm for special purposes. Each has been tested and validated by NIST for the FIPS 140-2 standard.
Can I bundle Encryptionizer with my application?
Yes! With the distribution license you can include transparent data encryption and/or column encryption in your distributed application. Use it to protect your own intellectual property, or enable your users to protect the data they enter into your application. We include instructions on how to build the installation scripts. Even if you are distributing Encryptionizer throughout an enterprise, you can create your own customized installation routines. See more information on our page for Application Developers and our Developer Versions.
Can I use Encryptionizer to become compliant with HIPAA, PCIDSS, etc?
While using Encryptionizer alone will not make you immediately compliant, Encryptionizer can be used as your compliance strategy. NetLib clients use Encryptionizer as part of the overall plan for HIPAA compliance, PCIDSS, FIPS 140-2
Transparent Data Encryption (TDE) – Encryptionizer vs. SQL Server
Encryptionizer’s TDE offers several advantages over SQL Server’s. We have included a brief comparison of Encryptionizer TDE and SQL Server TDE.
How is Encryptionizer different from EFS/BitLocker?
Encryptionizer offers several advantages over Operating System-based whole disk encryption. In fact, you will find Encryptionizer useful even if you already have Whole Disk encryption on your disk volume.
- Encryptionizer is an additional layer of security on top of Windows security. It can be controlled by the Data owner, separate from the Computer Owner, and the Windows, Domain or Network Administrators.
- Encryptionizer supports a wider variety of operating systems and media with a consistent method.
- Encryptionizer can be bundled and installed with an application ( Application Developers)
How do I place an order?
We highly recommend that you request an evaluation version before deciding to purchase Encryptionizer. This fully functional evaluation version will allow you to see how quickly Encryptionizer can be deployed as well as ensure that Encryptionizer satisfies your needs. Click here to request an evaluation version.
If you would simply like more information or would like to order Encryptionizer, please visit our Contact Us form.
Transparent Database Encryption
How do I deploy NetLib’s Transparent Database Encryption?
You start by using an included provided User Interface (or available Command-Line-Interface) to encrypt a database with a high level Encryption algorithm, a selected key length (up to 256 bit) and a pass-phrase. Next, you use another utility to secure your instance of SQL Server, MySQL or other application with the Encryptionizer engine. This allows your instance, and no other, to access your encrypted databases. Encryptionizer decrypts data on-the-fly completely transparently so that your application “thinks” it is using a “normal” database. There is no need to change any applications. What’s more, data is never decrypted on the disk, only in the server’s RAM for use by your application.
How does Transparent Database Encryption work?
Transparent Database Encryption encrypts an entire database file. This encrypted database cannot be accessed unless the SQL server, My SQL or other application is then secured with the same key. This prevents anyone from being able to steal the database file and view or attach it elsewhere. And it does this simply, with low maintenance and little or no impact on performance.
Take a look at How It Works for more detail.
This example uses SQL Server as the sample Database Management system, however, Enryptionizer works the same on any Windows based Database Management System like MySQL, DB2 or PostgreSQL. It also supports other applications such as FTP servers, off-the-shelf or custom applications.
How does Transparent Database Encryption protect backups?
Databases on backup media are as much at risk, if not even more so, than databases on the server. Of course you use a backup password, but anyone that needs to perform a backup or a restore needs to know the password. In fact, it is probably taped to the backup console! Encryptionizer can automatically encrypt a backup, as it is being created. This allows an additional layer of encryption, for which the backup operator does not need to know the key. What’s more, if someone takes the backup media and tries to restore your database to a different machine, or even instance on the same machine, it will appear as an unreadable backup.
How do I deploy NetLib Column Encryption?
Encryptionizer for SQL Server allows you to achieve column encryption is several ways. The simplest is through the use of our point-and-click user interface called the Column Encryption Manager (Col-E Manager, for short). Your first step is to create the server key. This allows you to choose a strong algorithm, key length (up to 256 bit) and a strong passphrase. Once the server key is set, you can use the Col-E Manager to select the column(s) to encrypt.
You can also choose to encrypt columns using the included API’s. You can use the API’s to perform encryption/decrypt activities directly within your application.
How does Column Encryption work?
If using the Col-E Manager, when you select the column(s) to be encrypted, the Col-E manager will encrypt the column data on disk, and then create views that control access to the encrypted data. INSTEAD OF triggers are also created to ensure that data is written as encrypted back to the database. You will use the Manage Permissions function to determine which users will have read access to the encrypted data and which will not. The Col-E Manager has a “transparent encryption” feature that will allow for encryption to be transparent to existing applications in most cases.
If using the APIs directly, user defined functions and stored procedures are all available for incorporation into your application.
Is the encrypted data protected in backups?
Column data that is encrypted is backed-up as any other column data would be when SQL databases are backed-up. If you need to restore encrypted data to another machine, that machine must be configured with Encryptionizer with the same key profile settings.
How does Col-E protect against frequently repeating values?
When encrypting data in columns, if a column contains the same value repetitively, that same value will typically be encrypted to the same encrypted value. While someone may not be able to discern what that encrypted value is, they will be able to determine all the records that have that same value. For columns that contain such repeating values, such as salaries (“Who makes the same as me?”), PIN’s (“Who has the same PIN? I just have to figure out one and I know the rest”), etc. that can be a risk. Col-E has a feature to protect against this risk called Repeating Values Protection (RVP). RVP ensures that each value in a column encrypts to a different encrypted value, thus obscuring the identical values.