microsoft sql server - townsend security · self-encrypting drives, ssds, etc file system...
TRANSCRIPT
ENCRYPTION &KEY MANAGEMENTMICROSOFT SQL SERVER
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Organizations large and small, public and private, are faced with daily
challenges to protect their sensitive digital assets. These might include
intellectual property, business plans and strategies, and sensitive data
of employees, customers, vendors, and stakeholders. The loss of this
sensitive data can be devastating to the organization and in some cas-
es represents a catastrophic loss. There is no alternative to a digital
existence and cybercriminals, political activists, and state actors have
become more and more adept at stealing this information.
Microsoft SQL Server has become a ubiquitous storage mechanism for
all types of digital assets. Protecting these data assets in SQL Server is
a top priority for business executives, security specialists, and IT pro-
fessionals. This eBook looks at various ways to protect sensitive data
in SQL Server databases using encryption – the most widely recog-
nized and accepted way to protect these assets. Of course, it should
be noted that encryption is only one part of a larger digital security
strategy. Getting data security right means deploying a wide set of
protection technologies and human procedures. Here we are only
looking at the critical security control of encryption.
Patrick Townsend, Founder & CEO,Townsend Security
“
”
Page 2
CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere
Page 3
CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere
ENCRYPTION IN THE BROADEST SENSE MEANS
obscuring information to make it inaccessible to un-
authorized access. But here we will use the term in its
more precise and common use – the use of well ac-
cepted encryption algorithms based on mathematical
proofs and which have been embodied and approved
as international standards.
Many approaches to encryption
do not meet minimal require-
ments for security and compli-
ance. Our definition of encryp-
tion excludes:
• Homegrown methods developed by even ex
perienced and talented programmers.
• Emerging encryption methods that are not yet
widely accepted.
• Encryption methods that are widely accepted
as secure, but which have not been adopted
by standards organizations.
• Data substitution and masking methods not
based on encryption.
An example of an encryption method that does meet
our criteria would include the Advanced Encryption
Standard (AES) which is sometimes knows as Rijndael,
Triple Data Encryption Standard (3DES), RSA, and Ellip-
tic Curve encryption methods.
ENCRYPTION
In the context of protecting data in a SQL Server data-
base, the most common encryption method protecting
whole databases or an individual column in a table is
AES. All key sizes of AES (128-bit, 192-bit, and 256-bit)
are considered secure and are appropriate for pro-
tecting digital assets. Many organizations chose 256-
bit AES for this purpose due to the larger key size and
stronger security.
One major additional benefit of using an industry stan-
dard such as AES is that it meets many compliance
requirements or recommendations for the use of in-
dustry standard encryption. This includes the PCI Data
Security Standard (PCI-DSS), HIPAA, FFIEC, and the EU
General Data Protection Regulation (EU GDPR).
EBOOK:THE ENCRYPTION GUIDE
DOWNLOAD
Page 4
CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere
IT IS NOT POSSIBLE TO DISCUSS AN ENCRYPTION
strategy without discussing the protection of encryp-
tion keys. An encryption strategy is only as good
as the method used to protect the encryption keys.
Encryption algorithms such as AES and Triple DES are
public and readily available to any attacker. The pro-
tection of the encryption key is the core to the security
of the encrypted data. This is why security profession-
als consider the loss of the encryption key as equiva-
lent to the loss of the digital assets. Once an attacker
has the encryption key it is trivial to decrypt and steal
the data.
Generating strong encryption keys and protecting
them is harder that it might at first appear. The gener-
ation of strong encryption keys depends on the use
of random number generation schemes, and modern
computers do not excel at doing things randomly.
Specialized software routines are needed to generate
strong encryption keys. Encryption keys must also be
securely stored away from the data they protect, and
yet must be readily available to users and applications
that are authorized to access the sensitive data. Au-
thenticating that a user or application is authorized to
an encryption key is a large focus of key management
systems.
Over the years standards and best practices have
emerged for encryption key management and these
have been embodied in specialized security appli-
cations called Key Management Systems (KMS), or
KEY MANAGEMENT
Enterprise Key Management (EKM) systems. The
National Institute of Standards and Technology (NIST)
has taken a lead in this area with the creation of Spe-
cial Publication 800-57 entitled “Recommendation for
Key Management”. In addition to this important NIST
guidance, the organization publishes the Federal
Information Processing Standard (FIPS) 140-2 “Security
Requirements for Cryptographic Modules”. To serve
the needs of organizations needing independent certi-
fication that a key management application meets this
standard, NIST provides a validation program for FIPS
140-2 compliant systems. All professional key manage-
ment systems have been validated to FIPS 140-2.
Page 5
CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere
When protecting sensitive SQL Server data with en-
cryption, look for these core principles of key manage-
ment:
• Encryption keys are stored away from the data
they protect, usually on specially designed
security devices or dedicated virtual services.
• Encryption keys are managed by individuals
who do not have access to the data stored
in the SQL Server database (Separation of
Duties).
• Encryption key management requires more
than one security administrator to authenticate
before performing any critical work on keys
(Dual control).
• Key retrieval requests from users and
applications are authenticated using industry
standard methods.
• Encryption management and key usage are
logged in real time and logs are stored on
secure log collection servers.
• Encryption key management systems
have been validated to FIPS 140-2 and the Key
Management Interoperability Protocol (KMIP).
These are just a few of the core requirements for
deploying a professional key management solution to
protect your SQL Server data.
PODCAST:SQL SERVER ENCRYPTION OPTIONS
DOWNLOAD
KEY MANAGEMENT (CONTINUED)
Page 6
CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere
ONCE WE MAKE THE DECISION TO ENCRYPT
data in our SQL Server database we then have to
decide where to implement that encryption. We have
a number of choices on how and where to implement
encryption. We could implement it using self-encrypt-
ing hard drives, or file or volume level encryption, or
in applications that use the SQL Server database. It
might help visualize these options by imaging a Five
Layer Cake like this:
At the very lowest level we have the disk drives that
store our data. At the next level up we have the file
input/output facilities provided by the operating sys-
WHERE TO IMPLEMENT ENCRYPTIONSECURITY & THE FIVE LAYERS
tem. Then we come to the database level where SQL
Server lives. Above that is the layer of our applications
that read and write information into the database. And
finally at the highest level we have the network layer
services that connect our endpoints.
Choosing where to implement encryption has securi-
ty implications. Generally, the higher the layer where
we implement encryption, the better security we can
achieve. But there is not a hard-and-fast rule about
this. There are some tradeoffs at each layer. The only
certain thing we can say is that not implementing en-
cryption leaves us terribly exposed to loss!
SELF-ENCRYPTING DRIVES, SSDs, ETC
FILE SYSTEM (FILE/FOLDER/VOLUME)
DATABASE
APPLICATION
NETWORK SERVICE
Page 7
CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere
AT THE VERY LOWEST LAYER OF OUR CAKE WE
have the physical storage mechanisms for our data.
This is a hard disk drive, flash storage, or a disk array.
It doesn’t matter if we are using cloud infrastructure,
traditional IT systems, flash storage, or a converged
technology. Data comes to rest on a physical storage
device.
Encryption can be implemented at
this layer. Self-Encrypting Drives,
or SEDs, are a good example of
this. Almost all disk drive manufac-
turers offer SEDs in their product
line. Even if you are deploying SAN
storage systems these can be de-
ployed with Self-Encrypting Drives.
SEDs insure that all data written to the disk, in fact
everything written to the disk, is encrypted. By default
each drive has an encryption key stored on the drive
and the drive firmware uses it to perform encryption
of the data stored on the drive. Key management may
optionally be used at the disk management level to
implement protection of the encryption key.
Encryption at Layer 1 provides the most basic protec-
tion. In essence, it helps prevent data loss if the drive
is removed from the system and it is subsequently lost
or stolen. Because the drive does not distinguish any
right of a user to the encrypted data, it is considered
the least effective level of encryption security.
LAYER 1
SELF-ENCRYPTING DRIVES, SSDs, ETC
Layer 1 encryption is implemented by hardware man-
ufacturers and is not something that an organization
can implement on their own. You must purchase disk
hardware or SAN storage from a manufacturer that has
implemented disk encryption in their solution. Most
disk drive manufacturers now provide self-encrypting
drives in their product lineup and it is not difficult to
source SEDs for the underlying storage of your SQL
Server database system.
Encryption key management varies a great deal from
one vendor to another. In some cases no key manage-
ment is provided, or a simple one-key implementation
is provided. However, as SED and SAN technologies
have evolved we are starting to see true key man-
agement capabilities in SED and SAN storage, usually
based on the KMIP standard.
Cloud service providers (CSPs) vary a great deal in
their implementation of disk level encryption. Many
larger CSPs offer encrypted drives as a default, al-
though some only offer this to their virtual private
cloud customers. Smaller ISPs may offer encrypted
drives at an additional cost, or not support this at all.
Customer control of encryption keys for disk encryp-
tion is non-existent and presents a challenge for orga-
nizations around key custody.
Encryption & Tokenization:
Key Management:
Secure Communications:
Logging:
Authentication
eBook
Podcast
Video
Blog
White Paper
Solution Brief/Data Sheet
Case Study
Resource Kit
Page 8
CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere
ENCRYPTION AT THE FILE SYSTEM IS THE NEXT
level in the hierarchy and is usually accomplished by
taking advantage of available operating system hooks
for file input and output. Layer 2 encryption may be
done at the file level, or for all files in a folder, or for all
folders on a volume. Typically, a block of data being
written to disk by a database or an application is in-
tercepted and encrypted on the fly. When data blocks
are read from the disk the data is decrypted and pre-
sented to the application.
With some file system encryption solution additional
security controls may be added. For example, the user
requesting the data read from disk may be validated
to insure proper authorization. However, many file
input/output systems defeat the ability to perform this
check by optimizing file I/O operations.
Generally the level of security with Layer 2 file system
encryption is a bit better than just disk encryption.
Encryption key management is often implemented
in more secure ways. There is, however, no granular
control over the actual sensitive information being
accessed, no ability to apply selective data masking or
access controls.
The Windows operating system now supports file and
volume level encryption with BitLocker. You will also
find a number of commercial systems that provide this
level of encryption. There are still operating systems
such as IBM Enterprise servers (IBM i or AS/400) and
LAYER 2
FILE SYSTEM (FILE/FOLDER/VOLUME)
IBM System z Mainframe where file system encryption
is not available or very minimal.
At Layer 2, encryption key management is still a major
challenge. Windows BitLocker does not implement
standard key management interfaces. Due to the
weakness in key management support the native Win-
dows BitLocker solution is not preferred by Enterpris-
es. Commercial solutions do a better job of address-
ing key management and are preferable for Layer 2
encryption.
Cloud service provides vary a great deal in the types
of file, folder and volume encryption services they
offer. For customers of Microsoft SQL Server this
layer of encryption will be managed in their Infrastruc-
ture-as-a-Service implementations of Windows SQL
Server.
Page 9
CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere
IN OUR LAYERED VIEW OF THE LANDSCAPE FOR
encryption, the database is at Layer 3. Almost all com-
mercial databases now support some type of encryp-
tion in the database itself and this includes SQL Server
since SQL Server 2008. This includes the encryption
of the entire table space which is called Transparent
Data Encryption, or TDE. And it includes the encryp-
tion of data at the column level which is called Column
Level Encryption or Cell Level Encryption (CLE). SQL
Server supports both of these approaches for Enter-
prise editions of the database.
Encryption at the database layer provides some dis-
tinct advantages:
• Encryption is optimized for database perfor
mance in way that is not possible in Layer 2 file
system encryption solutions.
• Encryption key management may be better
integrated into the encryption implementation.
• Encryption services are better integrated
with other database access control services
resulting in fewer security gaps.
There is still no standardization in SQL Server or other
database systems in how encryption is defined and
implemented. This means that database portability
remains an issue for organizations that desire to retain
a level of independence from the database vendor.
LAYER 3
DATABASE ENCRYPTION
In cloud environments SQL Server encryption is sup-
ported through Infrastructure-as-a-Service implemen-
tations and works exactly as it would in a traditional IT
data center.
WHITE PAPER:Encryption & Key Management for Microsoft SQL Server
DOWNLOAD
Page 10
CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere
IN OUR LAYERED VIEW OF THE ENCRYPTION
landscape the application is Layer 4. Application
encryption involves the use of an encryption library
and a key retrieval service, or an encryption service
provided by a vendor’s HSM
or a cloud service provider.
Encryption at the application
layer fundamentally means
that you are encrypting data
before inserting it into a
database or other storage
mechanism, and decrypting it
after you retrieve the data. It
provides a very granular level
of control of sensitive data
and allows for the application
of user accesses controls,
program access control, data
masking, and other security
controls. Many feel that application layer encryption is
the most secure way to protect data.
There are now many choices of encryption libraries for
use with SQL server. If you use SQL Server Extensible
Key Management (EKM) with Transparent Data Encryp-
tion, Microsoft uses their own AES encryption librar-
ies to perform encryption of the table space. If you
use SQL Server EKM Cell Level Encryption, you have
some choices in what encryption library you use. Most
developers will use the native Microsoft .NET AES
software library as it performs very well and is readily
LAYER 4
APPLICATION ENCRYPTION
available. Of course, if you are not using the SQL EKM
support, you still have access to the .NET AES encryp-
tion libraries.
If your applications are imple-
mented in a language such
as Java, PHP, Python, Perl or
other application language,
you have access to very good
encryption libraries provided
by the language. For exam-
ple, Java includes native AES
encryption libraries that you
can use for application layer
encryption. Other languages
offer similar support. It is now
rare that you would need to
look beyond the encryption
facilities of the development
language or operating system libraries to encrypt your
data in SQL Server.
With a Layer 4 encryption strategy you must also ad-
dress encryption key management. Key management
is not addressed by language or operating system
facilities in an adequate manner. This means looking
to a key management solution from a vendor or from
a cloud service provider. There are many vendors of
encryption key management that integrate well with
the Microsoft environment and SQL Server. These
offerings span traditional Hardware Security Mod-
“Encryption at the application
layer fundamentally means
that you are encrypting data
before inserting it into a
database, and decrypting it
after you retrieve the data.
Many feel that application
layer encryption is the most
secure way to protect data.”
Page 11
CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere
ules (HSMs), VMware instances, and native dedicat-
ed cloud offerings. Typically you will use a vendor’s
software library to retrieve a key, or you can use the
Key Management Interoperability Protocol (KMIP) to
retrieve a key. KMIP provides a vendor neutral method
of key retrieval, but may not offer the level of auditing,
high availability failover, and other features that are
important for enterprise customers.
Lastly, we should not overlook the option of using an
encryption-as-a-service mechanism. Many key man-
agement HSMs, VMware instances, and cloud key
management offerings also provide encryption as a
service. That is, you can send data to the key server
to be encrypted or decrypted and returned to your
application on a secure connection. This is often a
preferred method in more exposed environment like
web applications or kiosks as the encryption key is not
exposed in the process. With encryption as a service
care must be taken that the key server provides ade-
quate performance.
Generally cloud service providers and Infrastruc-
ture-as-a-Service implementations work at the applica-
tion layer as expected. With some Platform-as-a-Ser-
vice (PaaS) offerings it is important to review how well
the PaaS environment supports encryption and key
management.
APPLICATION ENCRYPTION (CONTINUED)
MORE INFORMATION
WEBINAR:ENCRYPTION & KEY MANAGEMENT WITH MICROSOFT SQL SERVER
VIEW WEBINAR
Page 12
CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere
THE FINAL LAYER THAT CAN PROVIDE
encryption for SQL Server resides at the network layer,
with some variations in the implementation. A Layer 5
approach inserts an application in front of SQL Server,
either as a node on the network layer, or as an imple-
mentation on the client side. This type of implemen-
tation encrypts data on the way to the server hosting
SQL Server, and decrypts the data after it leaves SQL
Server. A small number of third party vendors provide
this type of service.
LAYER 5
NETWORK SERVICE ENCRYPTION
In SQL Server 2016 Microsoft introduced Always En-
crypted, a client side architecture that encrypts data
at the client before it is transmitted to the SQL Server
database. This facility may be attractive to cloud cus-
tomers as all of data is encrypted before being stored
in the cloud. The issues of key custody are therefore
minimalized, as is the security risk in the cloud. Of
course, the Always Secure implementation is respon-
sible for both encryption and key management. For
some customers Always Encrypted will not be appro-
priate due to the limitations in the SQL functionality.
SUMMARY
MICROSOFT CUSTOMERS HAVE MANY CHOICES in how they ap-
proach encryption of sensitive data in Microsoft SQL Server databases.
Encryption is readily available in the Windows operating system (.NET
framework) and in the many languages used to build applications that use
SQL Server. The many choices mean that customers can readily find the
security they need at an affordable price. Compromises related to perfor-
mance and key management are no longer necessary, and the maturity
of the many vendor solutions takes the risk out of a SQL Server encryp-
tion project.
Page 13
CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere
“A very cost effective solution in terms of performance,
manageability, security, and availability. As a result, my company
was quickly able to implement full database encryption leveraging
the AKM as our key management solution in weeks. Comparable
solutions could have taken months.”- CERTAIN
TOWNSEND SECURITY IS HELPING MICROSOFT
SQL Server customers with Alliance Key Manager. The
solution includes the Key Connection for SQL Server
application to help Microsoft users implement Trans-
parent Data Encryption (TDE) and Cell Level Encryp-
tion (column level encryption) without the need for
application development. This application installs as
a service on SQL Server and provides the Extensible
Key Management (EKM) provider software. With inte-
grated support for multiple, redundant AKM key serv-
ers Microsoft customers can deploy encryption rapidly
and without programming.
Alliance Key Manager is FIPS 140-2 compliant and
in use by over 3,000 organizations worldwide. The
solution is available as a hardware security module
(HSM), VMware instance, and in the cloud (Amazon
Web Services, Microsoft Azure, and VMware vCloud).
Townsend Security offers a 30-day, fully-functional
evaluation of Alliance Key Manager.
ALLIANCE KEY MANAGER
30-DAY EVALUATION
ALLIANCEKEY MANAGER
REQUEST EVALUATION
• FIPS 140-2 and KMIP compliant enterprise key manager
• Available as an HSM, VMware, or in the cloud (AWS, Microsoft Azure)
• Affordably priced, with no restric tions on server connections or client side applications
• Meet compliance regulations like PCI DSS, HIPAA, FFIEC, and more
Page 14
CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere
TOWNSEND SECURITY CREATES DATA PRIVACY
solutions that help organizations meet evolving
compliance requirements and mitigate the risk of data
breaches and cyber-attacks. Over 3,000 organizations
worldwide trust Townsend Security’s NIST and FIPS
140-2 compliant solutions to meet the encryption
and key management requirements in PCI DSS,
HIPAA/HITECH, FISMA, GLBA/FFIEC, SOX, and other
regulatory compliance requirements.
CONTACT TOWNSEND SECURITY
www.townsendsecurity.com
@townsendsecure
724 Columbia Street NW, Suite 400
Olympia, WA 98501
360.359.4400
ABOUT TOWNSEND SECURITY