SQL Encryption: Difference Between NetLib Security’s Whole Database and Column Level Encryption Methodology
NetLib® Encryptionizer® is the only product line that can provide both whole database and column-level encryption for all Editions and versions of SQL Server. Below is a discussion of each of the methods by which data in SQL Server can be protected.
NetLib Encryptionizer Whole Database Encryption and Column Encryption products can be layered to provide the protections of both methods.
Whole Database Encryption Advantages
- Simplest to implement – a few clicks and it is done.
- No code changes necessary to applications
- Negligible performance impact (<1%) on typical transactions on a multi-processor server. More efficient and less impact than Column Encryption.
- Protects ALL information in a database including schema, stored procedures, all data points.
- Can encrypt Master and other system databases to protect security information.
- Prevents the database from being attached to an unauthorized instance of SQL Server .
- Can protect databases on backup media
- Can protect databases from the network, domain, or Windows administrators
- Can protect databases from the SQL sysadmin in certain cases (requires a dedicated SQL instance for the database).
- Can protect databases on laptops/desktops.
- Developers can use it to protect intellectual property, including proprietary business processes and schema of the database.
- Can be used to protect databases distributed on CD, over the Internet, etc.
- Optional APIs for encrypting non-database files such as documents, spreadsheets, or graphic images.
Whole Database Encryption Limitations
- Single key for the entire database
- Cannot protect against the SQL sysadmin in a SQL instance shared with other databases (can be mitigated by following Microsoft Best Practices for assigning authority)
Column Level Encryption Advantages
- More flexible in choosing which pieces of data to encrypt. Applications can be written to ultimately control when, where, by whom, and how data is viewed.
- Can protect data from the SQL sysadmin even where there is no dedicated SQL instance (requires custom programming).
- Contains both an API interface for maximum power and flexibility, and a seamless point-and-click interface for maximum ease of deployment.
- Different columns (and even different rows) can be encrypted with different keys (requires custom programming).
- Transparent encryption possible in some cases.
Column Level Encryption Limitations
- Performance Impact in typical transactions – 5-6 percent on average slower on accessing/updating an encrypted column versus plaintext column. The greater the number of columns encrypted, the greater potential for performance impact.
- Cannot encrypt primary or foreign key fields without changes to existing programs.
- Limitations on types of database searches that can be performed. For example, comparison searches on an encrypted column (e.g., LastName begins with “S”, Salary between $50,000 and $60,000) can result in table scans, which can be slow in a large database.
- Cannot protect the intellectual property of the database (e.g., schema, views).
Why is NetLib Encryptionizer’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.