SafeNet DataSecure vs.
Native SQL Server Encryption
Table of Contents
Executive Summary
Given the vital records databases
hold, these systems often
represent one of the most
critical areas of exposure for an
organization. Consequently, as
organizations look to comply
with security best practices and
regulatory mandates, database
encryption is becoming
increasingly common—and
critical. Today, security teams
looking to employ database
encryption can choose from
several alternatives. This paper
provides a high level comparison
of two approaches: Microsoft’s
native encryption capabilities for
SQL Server and the SafeNet
DataSecure platform.
Solutions Overview ................................................................................................................................................ 1
SafeNet DataSecure .......................................................................................................................................... 1
SQL Server Encryption .................................................................................................................................... 2
Security and Compliance ...................................................................................................................................... 3
Security of Keys ................................................................................................................................................. 4
Security of Data ................................................................................................................................................. 5
Separation of Duties ......................................................................................................................................... 5
Access Control and Leakage Prevention..................................................................................................... 6
Central Policy Control ..................................................................................................................................... 7
Infrastructure Coverage................................................................................................................................... 8
Integration and Administration ........................................................................................................................... 9
Total Cost of Ownership ................................................................................................................................ 9
Set Up and Integration ................................................................................................................................... 10
Persistence Support for Cross Platform Applications ........................................................................... 11
Key Management and Rotation .................................................................................................................... 12
Logging and Auditing ....................................................................................................................................... 13
Performance and Availability .............................................................................................................................. 13
Performance ...................................................................................................................................................... 13
Availability and Recovery ............................................................................................................................... 14
Conclusion .............................................................................................................................................................. 15
About SafeNet ....................................................................................................................................................... 15
Solutions Overview
SafeNet DataSecure
SafeNet DataSecure is the only appliance-based data protection solution that features granular,
field-level encryption capabilities that can be integrated at the file, Web server, application server,
or database layer. By centralizing cryptographic processing, key and policy management, logging,
and auditing in a single, hardened appliance, DataSecure maximizes overall security and helps
ensure organizations are compliant with a range of security best practices and regulations.
DataSecure features a centralized architecture that streamlines security administration and
provides superior key and policy life cycle management. Plus, DataSecure can act as an external
key management device for third-party encryption offerings. Consequently, organizations
employing SQL Server’s encryption capabilities can store the cryptographic keys associated with
that product, as well as keys for other encryption products, on the DataSecure appliance.
SQL Server Encryption
Microsoft offers several encryption options for SQL Server.
Windows BitLocker
BitLocker is an encryption solution that provides disk level, sector-based, and bulk encryption of
an entire drive or volume. BitLocker provides protection against data access when a machine is
turned off, but does not provide any protection once the operating system is started. Information
is stored on the disk in encrypted format at all times, which means performance is slowed by
approximately 5-10%, even when the client or server is turned on. However, any data requested
from the disk is immediately returned in a decrypted format, therefore, during day-to-day
operations of database servers, BitLocker introduces significant performance latency without
providing any granular data access protection. BitLocker is better suited for non-read/write
intensive usage, such as encryption of file servers or Windows clients, or for protection of hard
drives while in transit between sites.
Encrypting File System
Encrypting File System (EFS) is a file encryption feature introduced in Windows 2000, with
additional features and enhancements released in subsequent years. EFS makes it possible for
users to encrypt files on their computers, and control who can decrypt or recover these files.
EFS uses symmetric keys to encrypt files, and it uses certificates associated with a specific user
account to protect the file keys. For EFS to be used safely, an organization must have already
deployed a secured public key infrastructure (PKI) with hierarchical certificate authorities (CA),
and have the processes and mechanisms in place to securely manage certificates and keys.
While EFS is a very robust solution for encrypting files in Windows environments, it is usually not
recommended for database file encryption. EFS does not support column-level encryption, which
means the entire database file must be encrypted and decrypted while in use. As a result, EFS
typically introduces performance degradation of approximately 20 percent, which is especially
problematic for large database files. In addition, any user connecting to the database server can
access any data in an EFS encrypted database file, regardless of the EFS encryption status. When
EFS is used for database file encryption, the EFS encryption keys often reside in the operating
system hosting the database server, where they are vulnerable. Additionally, this requires a
smartcard or HSM to be connected to each database server, which necessitates additional
purchases and administrative complexity.
Field-level Encryption
SQL Server field-level encryption was introduced in SQL Server 2005 and is also supported
unchanged in SQL Server 2008. Field-level encryption supports granular encryption of parts of a
database or table by modifying the database schema and moving the data that is to be protected
into a binary data type. A set of schema modifications allow the data to be read and updated in an
encrypted format after the changes are implemented.
Because of the significant performance and manageability impacts of setting up field-level
encryption, Microsoft has shifted its main focus in SQL Server 2008 towards transparent database
encryption. Microsoft still recommends the use of field-level encryption in SQL 2008 for
scenarios in which organizations demand a high degree of data security and access control or
granular data access auditing capabilities. Microsoft cautions customers about the performance
impacts of field-level encryption because each field needs to be encrypted and decrypted
separately on the database server CPU, which degrades performance by 20-40 percent.
Transparent Database Encryption
Transparent Database Encryption (TDE) is a new capability introduced in SQL Server 2008, and is
only available as part of the Enterprise and Developer Editions. TDE uses a hierarchical key
management approach that is almost identical to the one employed by Microsoft’s field-level
encryption approach. TDE provides bulk encryption of all the data in a given database. TDE does
not enable column or field level encryption at this time. Rather than offering a specifically targeted
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 2 of 15
key and data encryption management console, TDE is tightly integrated with SQL Server and is
managed using the same DBA query interfaces and the Transact-SQL language as the database
server.
Table 1: Data Protection Capabilities
BitLocker
EFS
Fieldlevel
TDE
Optional
(requires
HSM
purchase)
Optional
(requires
HSM
purchase)
SafeNet
DataSecure
Data Encryption (3DES &
AES)
Encrypted Physical Backup
Column-level Access
Policies
Time-based Access Policies
Separation of Duties
Encrypted Logical Backup
Offloaded Encryption (with
the key outside of memory)
Secure Master Key Storage
FIPS Certified
Central Key Management
Protection for Data Load
(ETL) and Direct Database
File Access
The table above compares the capabilities of native SQL Server encryption
and those of DataSecure.
Security and Compliance
Optimizing security is the ultimate objective of employing database encryption. This section
compares the security offered by Microsoft’s encryption options and DataSecure, comparing such
critical areas as key security, and separation of duties.
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 3 of 15
Security of Keys
Native SQL Server Encryption
The single most critical aspect to ensuring that encryption yields the highest level of security
possible is the security of the cryptographic keys. Simply put, if keys are compromised, encrypted
data is compromised.
A key architectural foundation of Microsoft’s encryption solutions is that cryptographic keys
reside on the same database server as the encrypted data. For large organizations with dozens or
even hundreds of databases, this means cryptographic keys reside on dozens or hundreds of
servers. This presents security exposures for a few reasons:
Security best practices dictate that keys and the data they protect are separated. The
reason? If a server falls into the wrong hands, whether through theft, lost in shipment
for repairs, or a host of other reasons, thieves gain access to both the keys and the
data.
While Microsoft TDE offers a hierarchical key model, the root key is generated and
protected by the underlying operating system, which is at odds with standards such as
the Payment Card Industry Data Security Standard (PCI-DSS), which requires
separation between data access controls and operating system security.
If you look at security as a battle, the more fronts you do battle on, the harder
defense is. Protecting keys on many databases represents just such a challenge. It is
more difficult to have visibility into whether keys have been compromised; security
mechanisms need to be employed on each platform, etc.
Database servers are architected to optimize data access, not security. They have
multiple, unsecured access points and they’re often not stored in physically secured
locations due to operational needs. Database server backups pose similar risks and
further compound the number of places keys may reside, and where the security
battles take place.
All keys are stored in software and are, therefore, susceptible to vulnerabilities in the
underlying software, and so organizations cannot be compliant with the stringent
requirements of such standards as Federal Information Processing Standards (FIPS).
When keys are stored in the database server and the underlying operating system, any
vulnerability in either Windows server or SQL Server 2008 poses an immediate risk
to data security and requires immediate patching—which can make an impact on
business processing and data availability.
To address this security exposure, Microsoft developed a capability known as Extensible Key
Management (EKM), which enables administrators to store root encryption keys, such as the
server master key (SMK), in third-party hardware security modules (HSMs) that are designed
specifically for this purpose. Given this, administrators may use key management from SafeNet.
While this offers significant safeguards, there are several factors to consider:
Using EKM for HSM-based key protection is an option, not a requirement. By default,
encryption keys are stored locally on the database server. Implementing EKM introduces
additional complexity for database administrators (DBAs), who are, typically, already
consumed with database-related tasks. Further, these efforts require subject matter
expertise around HSMs and key management, which is not commonly a part of a DBA’s
background.
Although EKM supports HSM-based storage of keys, policies for key access are still
controlled on SQL Server, most often by DBAs, so there is no real separation of roles
among an organization’s DBAs, developers, and the security organization. This
jeopardizes compliance with such standards as PCI-DSS, and makes the DBA the
responsible party in the event of a data leak or compliance violation, a responsibility
usually better handled by a security or compliance team.
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 4 of 15
The EKM approach introduces increased complexity and the additional cost of acquiring,
integrating, and managing the HSM, which is multiplied by the number of HSMs required
to support each and every database server separately.
DataSecure
With DataSecure, organizations can centrally house the cryptographic keys used to encrypt data
in virtually any number of databases. Simply by reducing the number of places they reside,
DataSecure dramatically reduces the potential exposure of cryptographic keys. Further,
DataSecure offers the highest level of security available in a commercial database encryption
solution. DataSecure operates on a hardened appliance that is validated to FIPS and Common
Criteria Evaluation.
Encryption keys are securely stored on the appliance and thereby protected against application
layer attacks and malicious DBAs and developers. The keys are never distributed to database
servers from the appliance nor can they be viewed or copied by anyone.
Security of Data
Native SQL Server Encryption
SQL Server TDE encrypts information when it is read to or written from the SQL Server buffer
pool. Consequently, information stored in the SQL Server memory cache is available in clear text
even if encrypted in the database, and therefore might be exposed through the Windows swap
file, SQL Server’s full text indexing, or in the event of a SQL Server memory dump.
DataSecure
DataSecure integrates cipher operations into the SQL statements themselves. As a result,
encrypted information is only decrypted when an actual select statement is executed, and is
immediately encrypted when an insert or update is called. Further, even when mechanisms, such
as a SQL Server checksums, buffer an actual write to disk, data remains encrypted. This ensures
that sensitive information is protected regardless of the access mechanisms being employed.
Separation of Duties
Native SQL Server Encryption
Many breaches in recent years have illustrated the risk of having one person holding all the “keys
to the kingdom.” That is why so many regulations and security policies mandate a separation of
duties when it comes to securing sensitive data.
When native encryption is employed on SQL Server, the DBA effectively also becomes the
security administrator. It falls to the DBA to install and maintain the encryption solution. Not
only do they handle traditional tasks, but they also must be relied upon to do key management,
set security policies, and control user access. Consequently, a single person controls the data,
which can present a significant source of exposure. Further, DBAs are not typically trained to do
security administration, which raises the potential for configuration errors. Finally, if one DBA
decides to undertake malicious activities, the harm they could inflict could be devastating.
TDE allows a DBA to grant the right to manage and create keys to specific users, therefore
separating the key management capabilities. However, the database system administrator still has
full rights to all aspects of the security of the database server, including keys. This may present a
challenge when addressing some compliance requirements, especially given some that commercial
applications require the use of system administrator privileges to execute correctly.
DataSecure
The DataSecure solution provides a mechanism for clearly separating security responsibilities
from database responsibilities as required by such regulations as PCI-DSS. Separation of duties
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 5 of 15
between the DBA and the other administrators prevents “super user” access and its associated
risks.
DataSecure offers granular capabilities for defining roles and permissions around the ability to
manage keys, create keys, and modify policies. DataSecure also allows for “M of N” approvals,
which means that organizations can set up policies so that no single administrator can make a
critical configuration change without additional approvals from other administrators.
With DataSecure, administrative privileges can be separated among a number of roles. For
example, a security administrator can be authorized to perform specific key management, user
access, and security policy functions; a network administrator could have control over device
configuration and certificates; an operations administrator could have logging controls; and the
DBA could have rights to perform database software installation and configure the tables and
columns to be encrypted.
Access Control and Leakage Prevention
Native SQL Server Encryption
Over the last few years, Microsoft has invested heavily in elevating the level of security offered
within its different product lines. As part of those investments, several impressive encryption
technologies have been introduced as part of both Windows servers and clients, as well as SQL
Server. These technologies are very useful, and should be utilized by customers where
appropriate.
While Microsoft BitLocker, EFS, and TDE provides a variety of encryption mechanisms, they
don’t provide protection over who can access the sensitive information, when they can access it,
or how much data can be accessed. In fact, these mechanisms are “blind” to the actual
information, allowing anyone with access rights to decrypt any information and use the data
encryption keys (DEK) regardless of the context.
This creates a serious threat to sensitive information, opens the door to leaks and liability, and
poses a serious threat to compliance, as standards, such as PCI-DSS and GLBA, require control
and management over data access rights. For example, when TDE is employed, applications
typically use a trusted subsystem account to access the database. There is no way to distinguish
such factors as the time of day data is being accessed, the server accessing the database (for
example, why would a server in the DMZ need to decrypt a large number of records?), or the
actual application or database user conducting the operation.
The following is a quote from Microsoft: “TDE is not a form of access control. All users who
have permission to access the database are still allowed access; they do not need to be given
permission to use the DEK or a password.”1
Further, when TDE is employed, data is encrypted at the database level, rather than at the
column level. As a result, anyone permitted to access the database can see all the data in the
clear. Consequently, organizations looking to employ encryption are faced with an all-or-nothing
approach—even though the sensitive data held in many databases will only amount to one or a
few columns out of many.
When field-level encryption is employed, keys can be either assigned to a database, in which case
the keys are stored on the database server and experience the same issue outlined for TDE, or
alternately be assigned to users and protected by passwords to prevent automatic decryption, so,
for example, users can have individual keys for their own data. Assigning keys to individual users
1
Microsoft, “Database Encryption in SQL Server 2008 Enterprise Edition”; Section: “Impact on the Database”—
http://msdn.microsoft.com/en-us/library/cc278098.aspx#_Toc189384679
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 6 of 15
addresses the issue of having a “master key” managed by the DBA, but, at the same time,
introduces a significant key exposure and management challenge since keys are stored on each
workstation on which the user needs to be able to decrypt the database information.
When EFS is employed, access control can only be applied to the file system files holding the
different database contents, such as database files, transaction log files, and full-text index files.
While EFS protects those files from offline attacks, such as someone attempting to copy the
database file itself, this only offers limited protection—database files are usually protected when
the operating system is shutdown by means such as full disk encryption, and are locked and will
prevent copying once the database server is running. Further, since the only “user” accessing the
database files is the account under which SQL Server is running, access control applies to this
user only. As a result, the EFS encryption keys must be available locally on every server used to
run SQL Server.
EFS does not provide any access control or protection over the actual data records inside the
database, nor can it protect data load and transform (ETL) files, since EFS does not provide any
centralized policy over the location of files that should be encrypted. Also, system administrators
must use the server console to manually encrypt files.
DataSecure
DataSecure offers authorization functionality that is highly granular so that access to encrypted
columns can be controlled by assigning encrypt and decrypt privileges on a per user basis. Plus,
these access control features allow a security administrator or compliance officer to secure
access to sensitive data at the user level. Often, these changes can be implemented with little or
no changes to the database architecture. While, in some cases, additional columns may be added
to such database elements as tables to support transparent data encryption, those changes have
no affect on the original database fields in the schema, which helps ensure full application
compatibility.
With DataSecure, a database user that has access to a table with encrypted columns may be
allowed to see all, none, or some of the encrypted data based on the way permissions are
configured. DataSecure separates the database access control managed by the DBA and the
application from the rights to use encryption keys and from the right to access protected
sensitive database information. DataSecure provides granular control over data access based on
the following parameters:
o
o
o
Time of day—Enables administrators to dictate when specific users and roles can
access sensitive data; for example, to ensure a call center employee that works the
day shift can’t access credit card information at 2:00 AM.
Amount of information being accessed—Organizations can control the volume
of decryptions; for example a call center representative that might need to handle at
most 100 customer records per shift will not be able to decrypt more than 100
records during a given day.
Policies and keys—Enables the segmentation of policies associated with the data
and the key used to encrypt it; for example, a call center employee might be able to
decrypt customer records in their line of business’ database but not in the VIP
customer table encrypted with a different key.
Central Policy Control
Native SQL Server Encryption
Another key challenge when utilizing Microsoft’s integrated encryption offerings is the lack of a
central policy management console that can be used to control encryption and policy changes. As
a result, it is difficult to maintain consistent documentation of the encryption and access controls
employed during a given time frame. With EFS and BitLocker, access control is managed locally
on both the database server and the operating system and must be set separately for every piece
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 7 of 15
of protected information, which presents a host of security management and compliance
challenges.
DataSecure
DataSecure provides a central, Web-based management console, that centralizes all access
control management in a single location. As a result, administrators have efficient access to a data
protection policy repository that displays all access policies—across different databases,
applications, and file systems. Further, DataSecure supports streamlined security configuration
documentation, which is a requirement for security life cycle management and compliance with
such regulations as SOX and PCI.
Infrastructure Coverage
Native SQL Server Encryption
It is important to note that while Microsoft does provides data encryption solutions for SQL
Server and file data, those solutions only address SQL Server on Windows operating systems.
Further, TDE can only be employed on SQL Server 2008, not earlier versions of the database.
The reality, however, is that sensitive data is housed and accessed in a host of other areas
throughout an organization—unstructured files, such as PDFs and spreadsheets, applications;,
Web servers, and more. Further, most organizations have a mix of operating systems and
databases installed, whether IBM DB2, Microsoft SQL Server, Oracle, or Teradata—and over the
course of its lifecycle, a specific piece of data may reside on a number of platforms. For example,
a customer record might be created in a mainframe application using DB2, copied to SQL Server
on Windows, loaded into an ERP application using Oracle on Linux, and finally forwarded to a
data warehouse housed in Teradata that is used for business intelligence reporting. Consequently,
native SQL Server encryption doesn’t address the full life cycle of corporate data, and so only
addresses a very small piece of an organization’s overall security needs.
As a result, many companies utilizing a variety of databases in their corporate networks end up
deploying and supporting security solutions on a database-by-database basis. Particularly in large
organizations, these point solutions prove costly and inefficient, and introduce their own set of
security problems. For example, since there is no key sharing between these disparate offerings
data has to be decrypted and forwarded in the clear before it can be encrypted on another
system.
DataSecure
DataSecure can be used to centrally manage the encryption of sensitive data in all of an
institution’s databases, including Oracle, IBM DB2, SQL Server, and Teradata.
DataSecure also provides the flexibility to encrypt data at the file level, at the column or field
level in databases, at the application layer, and during batch-driven data transformation and
transaction processes. DataSecure offers comprehensive support for sensitive database
information protection, regardless of the underlying operating system, featuring support for
Z/OS, Linux, Windows, and other platforms.
DataSecure provides the ability to encrypt information from the moment it enters the enterprise
and as it travels within the environment. With DataSecure, organizations can encrypt sensitive
data once, and have it be secured throughout its lifecycle, while at the same time enabling
authorized users and processes to decrypt the record when needed. This increases overall
security by eliminating points of vulnerability outside the database.
Table 2: Database Information Protection Components
BitLocker
EFS
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 8 of 15
Cell-level
TDE
SafeNet
DataSecure
Extensible Key
Management
Infrastructure1
Application-level
Encryption
File Encryption (outside of
SQL Server)
z/OS Integration
Integration with POS
Vendors
Oracle & DB2 Support
Support for RC4, HMACSHA1, and RSA
The table above outlines the support DataSecure and Native SQL Server encryption options
provide for various security capabilities that are required beyond database encryption.
Integration and Administration
The degree to which an encryption solution facilitates deployment and ongoing administration
efforts can play a significant role in the success of an encryption initiative. Following are details of
the differing integration and administration characteristics of each encryption approach.
Total Cost of Ownership
Native SQL Server Encryption
While Microsoft offers both file and database level record encryption, this support is only
available on SQL Server 2008, Enterprise Edition. As a result, implementing TDE requires that all
servers within the compliance area must be upgraded to SQL Server 2008, a large and timeconsuming task that can create application compatibility issues.
Further, the TDE solution is only applicable to SQL Server 2008 databases, so organizations with
other databases or operating systems are tasked with learning, implementing, and managing
separate solutions for each of those platforms.
To guarantee free software updates for the database platforms, customers are required to sign a
3-year maintenance plan with Microsoft, which tends to cost around 120 percent of the initial
purchase cost. The Microsoft maintenance plan does not include support fees, which are charged
separately and range from tens to hundreds of thousands of dollars depending on the support
needs. Any upgrade or fix to the encryption and key management solution requires a patch of the
database platform and/or the operating system, a process involving compatibility testing and
potential up-time implications.
DataSecure
DataSecure is a single, easy-to-manage solution that offers database encryption for all major
versions of Microsoft SQL Server, as well as other leading database platforms, such as Oracle,
DB2, and Teradata. DataSecure eliminates the need for expensive and lengthy application and
database migration and testing projects. Further, by having a single, easy management interface for
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 9 of 15
all database platforms and the related policies and keys, DataSecure significantly lowers
operational costs.
While the DataSecure appliance does require an initial purchase cost, this investment can be fully
leveraged as the appliance re-used across database platforms. The DataSecure maintenance plan
includes full support and software updates for all aspects of the DataSecure solution for a
relatively low yearly cost, and a seamless upgrade experience that removes any operational and
testing costs.
Set up and Integration
Native SQL Server Encryption
In all but the smallest organizations, deploying native SQL Server encryption is highly complex and
time-consuming. All administrative efforts are manual and conducted on a per-database basis, so
the more databases an organization has, the more work, and potential errors, will be involved.
In a common TDE deployment, in which the goal is to secure data and achieve regulatory
compliance, organizations must address several time consuming and complex requirements:
o
o
o
o
o
o
o
o
o
The need to have a PKI infrastructure available to provide for recoverable server and
database keys
The purchase, deployment, and secure operation of a FIPS Level 2-certified HSM for
each database server, in order to adhere to security best practices and regulatory
compliance
Manual review, outline, and implementation of data and key access policies
Separate deployment of file encryption
Development of scripts and command line tools to encrypt data during ETL processes
and in transit
Upgrade existing databases to SQL Server 2008 Enterprise Edition and associated
application compatibility testing
Ongoing patching of both Windows and SQL Server to address any vulnerability that
might affect TDE
Manual documentation of the key and data access rights as part of security life cycle
management and regulatory compliance
Institution of security training for the DBA team and establishment of a data exposure
response team that is comprised of several groups, including security, compliance,
application development, and DBAs
DataSecure
By providing an out-of-the-box solution with centralized administration of cryptographic policies
and configuration, DataSecure dramatically reduces implementation time and expenses compared
to deploying native SQL Server encryption. DataSecure offers centralized management for
securing database and applications across hundreds, or even thousands, of geographicallydistributed locations. Users can centrally manage every facet of security administration, including
key management, maintenance and troubleshooting, policy management, logging, reporting, and
software upgrades.
With DataSecure, integration across various database platforms is automated and transparent to
applications. In addition, DataSecure features these tools and capabilities:
o
A data discovery tool that can scan databases for sensitive data—such as account
numbers, credit card numbers, social security numbers, and e-mail addresses—that is
not encrypted, helping database administrators and security directors quickly identify
where sensitive data exists. This saves administrators time and enables them to better
secure sensitive information
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 10 of 15
o
o
o
Data migration capabilities that automatically configure the database and encrypt all of
the data in the columns that have been tagged for encryption
Application transparency, through support for the creation of triggers and views that
hide encrypt and decrypt functions from associated applications
Key rotation and versioning capabilities that enable administrators to rotate
encryption key(s) on a per column basis—without having to decrypt and re-encrypt
data.
Given DataSecure is provided as a turnkey, appliance-based solution, implementation is typically
fast and efficient. Following are the common steps to setting up database encryption:
o
o
o
Plugging in the DataSecure appliance and configuring network settings.
Connecting the appliance to the database to be secured, and selecting the appropriate
columns or fields to be protected.
Assigning keys, defining access policies, and migrating data to a protected state
Persistence Support for Cross Platform Applications
Native SQL Server Encryption
While native SQL Server encryption protects information in the database, it does not enable
organizations to integrate cryptographic operations with associated applications. However, in
many cases, it is preferable to implement data encryption in the application logic rather than in
the database. Not only does this approach often eliminate the need to make database
configuration changes and address performance degradation, but it can help ensure end-to-end
encryption of data, from the time it is entered to the point at which it is stored or viewed.
While Microsoft does provide encryption API’s, they are stand-alone and are not integrated with
underlying key management and data access policy management processes. Thus, organizations
that need to protect data across the entire processing lifecycle must implement several
disconnected integration and development projects to employ application-level and database-level
encryption.
DataSecure
The DataSecure solution was designed from the outset to support heterogeneous environments
and encryption at different levels within the infrastructure. With the DataSecure platform,
encryption keys used for one vendor’s database can be used for any other database system or
line of business application. DataSecure offers an extensive set of application connectors that
deliver FIPS-certified encryption to an organization’s line-of-business applications.
With DataSecure, encryption keys and data access policies can be re-used across different
applications and database systems, providing true information life cycle protection. With its
support for J2EE, .Net, COBOL, C, and other languages, DataSecure can be deployed in leading
application development and run-time environments. DataSecure supports seamless encryption of
the data, from its submission in a Web or line-of-business application, across enterprise
connectivity and integration layers (such as message bus and EAI), and in the database.
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 11 of 15
Figure 1: DataSecure offers a centralized solution for managing keys across an enterprise
infrastructure, including Web and application servers, databases, file servers, and more.
Key Management and Rotation
Native SQL Server Encryption
With native SQL Server encryption, keys are created and managed on the database server, and
administrators are tied to using Microsoft’s proprietary techniques and interface for performing
these functions. When there are large numbers of database servers in an organization, the
process of managing keys on each individual database server can quickly become cumbersome
and subject to errors. This is especially true if granular, field-level encryption policies are
employed. Further, there is no automated process to share or replicate keys among the database
servers, even within a single vendor’s platform. Backing up the keys, which is critical for any
encryption implementation, is a manual, command line process for each database on each
individual server and grows increasingly complex as the number and variety of database servers
are deployed throughout an organization.
Further, key rotation is required to increase the security of protected data, ensuring keys and the
data they protect do not get exposed over time. SQL Server 2008 supports key rotation by
generating a SQL script that generates a new key, backs up the existing and new keys to a file,
and re-encrypts the entire database with the new key. This operation will switch the existing data
to be encrypted using a new key, but while this operation is underway, the database will be
locked, preventing any use of the database for the duration of the process. Further, a massive
amount of processing overhead is incurred because, rather than encrypting a specific column, the
entire database needs to be decrypted and re-encrypted.
Command line backup of keys to a file does provide for recoverability of data in case of a disaster
or database issues, but requires an organization to setup and maintain a manual, unmanaged, and
less secure key repository, perhaps by keeping all backed-up keys in a central file server
directory, exposing the keys to risk and accidental deletion or loss.
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 12 of 15
DataSecure
The SafeNet DataSecure solution streamlines key management, providing a centralized network
appliance to perform all key management functions—including creating keys, controlling access to
keys, and backing up keys. DataSecure supports granular, fully automated key rotation, according
to key expiration policies. Further, this rotation only affects encrypted columns, minimizing the
performance impact of encryption on the database.
Logging and Auditing
Native SQL Server Encryption
Native SQL Server encryption only provides very basic logging information in heterogeneous
environments. This can be exacerbated by the fact that each database vendor will have its own
unique log format. Because of this, administration of logs and report generation is extremely time
consuming. Further, because of the way event data is structured in Windows and SQL Server, it
is very difficult to analyze log information and spot potential threats in a timely manner. In
addition, these logging mechanisms offer little protection against tempering or unintentional
modification.
DataSecure
DataSecure provides comprehensive, secure, and centralized logging and auditing of all
cryptographic functions and data access events. The DataSecure platform maintains a variety of
detailed logs to record all administrative actions and cryptographic activity on the appliance. Not
only is every cryptographic function logged, but real-time reporting allows for immediate
detection of any potential threats.
DataSecure can capture all encryption activity—even across disparate databases and
applications—and house this logging data in a central, standardized fashion. Compared to the
traditional, time-consuming process of manually gathering and analyzing information from multiple
application and database logs, this centralization provides much greater efficiency and control.
Consolidated logging information and audit reporting enables auditors to easily understand who
accessed what data and which administrators made changes to encryption configurations or key
management policies. DataSecure tracks administrative actions, such as key creation, access
control management and policy management to an audit log.
Further, DataSecure offers a detailed activity log, tracking all key usage and data access activity,
including details such as accessing user, time of day, amount of records accessed, related policy
and more. All logs managed by DataSecure are tamper-proof to allow for proof of authenticity
over the events record, which guarantees a clear, auditable history of data and user activity
across all sensitive information. Consequently, administrators can more efficiently comply with
the logging and auditing requirements of such regulations as PCI-DSS.
Performance and Availability
Given the vital role databases play in today’s infrastructures, performance and availability of
encryption and associated processes is a critical consideration. The following section compares
the performance and availability characteristics of native SQL Server encryption and DataSecure.
Performance
Native SQL Server Encryption
With Native SQL Server encryption, cryptographic processing and capabilities get added to a
database platform that was not originally designed for, or optimized for, security processing.
Further, since cryptographic processing takes place on the same machine as other business
applications, the performance of these systems often starts to suffer. This performance
degradation can be especially pronounced in performance-intensive batch processing and OLTP
environments.
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 13 of 15
Microsoft has officially stated that systems in heavy daily usage should expect up to a 28 percent
performance hit just from employing TDE, and organizations employing EFS or Biltlocker can
expect an additional performance hit of 5-20 percent. In addition, during data migration
operations (for example, when initially deploying encryption), performance suffers even more
dramatically. The following is a quote from Microsoft SQL 2008 PCI compliance guide: “Because
the initial encryption scan spawns a new thread, performance is most sharply impacted at this
time; expect to see queries perform several orders of magnitude worse.” 2
To boost performance, organizations have no choice but to add more database servers to their
infrastructure, which represents not only more upfront costs, but ongoing administration—and it
further compounds the risk of having keys and encryption managed in a disparate fashion.
DataSecure
By offloading cryptography to a dedicated and specialized cryptographic appliance, DataSecure
delivers better performance than SQL Server’s native encryption, especially during batch
processing.
DataSecure also provides special batch processing utilities for both database tables and flat files
that need to be imported or exported. These utilities are designed to take advantage of the highspeed cryptographic accelerator hardware in the DataSecure appliance and are ideally suited for
many batch applications. As a result, DataSecure can transform large databases into encrypted
format, or rotate the keys on existing data and completely re-encrypt it, with minimal impact on
the live database system.
Both from a performance and security standpoint, it is typically recommended that organizations
offload encryption from database platforms and onto the DataSecure appliance. However, in
some cases, database administrators prefer to handle this encryption locally on the database
platform. In these cases, DataSecure will also support this approach, enabling organizations to
employ cryptographic processing on the database server itself.
Availability and Recovery
Native SQL Server Encryption
TDE uses a key hierarchy comprised of a master data protection API (DPAPI) key, a server
master key (SMK), and a set of database keys (DMK). All SMKs and DMKs are stored within the
SQL Server master database, and the user is required to manually backup the keys to file using
SQL statements to ensure data is recoverable in case of a disaster. Further, since all key backup
operations are manual and need to be performed on each database server, the process of
managing a secure backup repository of keys, key locations, and the intended use of keys
becomes an intense and complex challenge.
For an organization to be able to restore a database from backup in case of a disaster, such as
storage or server failure, all elements of the key hierarchy—as well as the Windows operating
system and the database itself—must be restored from backup. This complex operation requires
a precise sequence of actions, complicating recovery procedures and delaying recovery times.
DataSecure
Since all keys and policies are stored within the DataSecure appliance, there are no dependencies
for recovery on the SQL Server or the operating system. In case of any issue with the database,
all that is needed is a restore of the latest version of the database, and DataSecure will
automatically enforce the relevant decryption and encryption policies.
2
Microsoft, “Database Encryption in SQL Server 2008 Enterprise Edition”; Section: “Impact on the Database”—
http://msdn.microsoft.com/en-us/library/cc278098.aspx#_Toc189384684
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 14 of 15
Further, DataSecure supports high-availability clustering, securely replicating all keys and policies
between all cluster members to ensure 99.999% uptime. DataSecure clusters can be deployed
across site links to support multiple geographic locations and disaster recovery sites. DataSecure
offers integrated, secured, and automated backups of the key and policy store for rare scenarios
in which all DataSecure machines in all geographic sites go down.
Conclusion
In recent years, Microsoft’s native encryption infrastructure has been enhanced, but these
offerings still represent a series of technologies, rather than a complete solution. Today, when
native SQL Server encryption is employed, cryptographic keys and policies are managed in a
disparate fashion, one database platform at a time. This can present a host of security threats, as
well as a high degree of administrative complexity, particularly in larger organizations. With
DataSecure, security administrators can leverage a single, centralized encryption solution, not
only for encrypting data in multiple SQL Server databases, but other database platforms,
applications, files, and more. As a result, DataSecure provides significant advantages both in
delivering optimal security and manageability.
About SafeNet
In 2007, SafeNet was acquired by Vector Capital, a $2 billion private equity firm specializing in the
technology sector. Vector Capital acquired Aladdin in March of 2009, and placed it under
common management with SafeNet. Together, these leading global companies are the third
largest information security company in the world, which brings to market integrated solutions
required to solve customers’ increasing security challenges. SafeNet’s encryption technology
solutions protect communications, intellectual property and digital identities for enterprises and
government organizations. Aladdin’s software protection, licensing, and authentication solutions
protect companies’ information assets and employees from piracy and fraud. Together, SafeNet
and Aladdin have more than 50 years of security expertise in more than 100 countries around
the world. Aladdin is expected to be fully integrated into SafeNet in the future. For more
information, visit www.safenet-inc.com or www.aladdin.com.
SafeNet
Corporate Headquarters
4690 Millennium Drive
Belcamp, MD 21017
Tel: +1 410 931 7500
Tel: 1 800 533 3958 - Sales
TTY Users: +1 800 735 2258
FAX: +1 410 931 7524
www.safenet-inc.com
©2009 SafeNet, Inc. All rights reserved. SafeNet and the SafeNet logo are registered trademarks of SafeNet, Inc. All
other product names are trademarks of their respective owners.
White Paper: SafeNet DataSecure vs. Native SQL Server Encryption—Page 15 of 15