After our latest webinar “Encryption & Key Management with Microsoft SQL Server” there were a number of great questions asked by attendees and answered by security expert Patrick Townsend.
Here is an informative recap of that Q&A session:
Q: Are there any special considerations when deploying an encryption key manager in the cloud?
A: The cloud always presents some additional security challenges related to encryption and security in general and has the impression of being less secure and having some new challenges around security. In the cloud, the encryption key manager itself is only one component to consider, and you need a good FIPS 140-2 compliant solution like our Alliance Key Manager for SQL Server. You also need client side applications and libraries, so when you're thinking about moving to the cloud, paying attention to that particular issue is very important. Also know that not all libraries can easily migrate to cloud. We develop ours from the ground up with the cloud in mind, so all of our components that talk back to our key manager for encryption keys or encryption services are cloud-enabled and can be deployed there.
From a compliance point of view, it is very important to take a look at the Cloud Security Alliance (CSA.org) document on cloud security - version 3.
We also provide a compliance brief about domain 11 which talks about encryption key management and issues around the security in the cloud.
Q: Can you go a little more in-depth about what gets installed on SQL Server?
A: For the SQL Server platform (the client side software) Microsoft allows for Extensible Key Management (EKM) which allows vendors like Townsend Security to plug into their environment. Our Key Connection for SQL Server is an EKM provider and it is a GUI (Graphical User Interface) install, so you load it on your own SQL Server platform and it walks you through some questions:
- It will ask what SQL Server instances you want to protect
- It will ask for your authentication credentials in order to execute the necessary commands
- It will allow you to install certificates into the Windows certificate store that are used to communicate with the key manager HSM
- It allows you to define the location of your production and multiple high-availability failover key servers (most companies deploy one production and one HA key server. However, you can actually identify a more complex environment if needed)
- Then it allows you to actually test, right there in the install dialog, your connection to your key manager to confirm it is working the way it is supposed to
Side Note: We do not charge based on the number of endpoints that talk to our Alliance Key Manager. This is something that is unique to us as a vendor. We believe the encryption should be easy to do and affordable, so no additional license fees are required to actually use it. We want our customers to deploy encryption and use it to protect data.
Q: What are the minimum requirements for the key server?
A: The Alliance Key Manager product is available as either a hardware security module (HSM) device or virtual appliance. As an HSM it has a 1U server footprint, so it looks like any normal 1U server in your data center. However if you use our Alliance Key Manager Cloud HSM implementation, the encryption key manager is installed for you in a secure data center. It is also our philosophy that these are customer install processes, so we don't have consulting fees because it is a user deployed device. The server administration is done through a secure web browser session with our Townsend Security technical experts. The encryption key management security functions are done through a specific Windows application that talks to one or more key servers to actually create and deploy encryption keys whether they’re for Oracle or SQL Server EKM.
Also, we do provide our encryption key manager as a VMware virtual appliance, which allows you to deploy a key manager within your VMware infrastructure and we give you guidance on that process. With this option you don't have to purchase a hardware appliance, you can run it in your VM infrastructure or within a vCloud architecture. We strongly recommend that a review of the PCI Security Council's - Cloud Computing Guidelines as well as their guidance around virtualization when deploying a virtual encryption key manager.
Q: Does your key manager handle encryption and decryption or just key management?
A: Our encryption key management appliance itself does support on-board encryption and decryption.
Q: Can the same EKM module be used to encrypt servers in both data centers and cloud environments?
A: Yes. You can mix and match these anyway you want. You can use the same encryption key management solution for applications running in either environment, and they can talk to each other. You should be aware of a good security practice guidance around using different encryption keys for different kinds of applications, or different user communities, even in a high-availability data center or disaster recovery centers.
Q: What are the performance impacts on encryption?
A: Encryption always has performance impacts. Generally it can impose a penalty somewhere between 2% and 4% in terms of computing resources. Guidance from Microsoft regarding very large SQL Server databases show that performance can become an issue with certain operations. For example, encrypted indexes may require the entire index to be decrypted in order to be processed. Very large SQL Server databases can impose a bigger performance penalty than 4%. Sometimes, cell level encryption has been a better performing implementation than transparent data encryption. We support both TDE and cell level encryption, allowing our customers to use our product as needed.
We strongly recommend to our customers, especially those with larger more complex SQL Server applications, that they contact us and ask for a complimentary evaluation of our encryption key manager. The complimentary product trial is fully functional and allows an opportunity to do analysis of the performance impacts. We want you to give it a try and make sure you understand the impacts personally.
Q: Is there any limit to the number of servers that you can hook up to the key manager?
A: No. There's no license limit. If you're considering putting up multiple servers we recommend you engage our pre-sales support team and get some guidance on your project. You will never come to us for additional licensing fees around adding a new platform, new SQL Server, or any other application that talks to the encryption key management server. We are unique in the industry that way and is part of our philosophy; we believe encryption needs to go everywhere, data needs protection wherever it lives, and we should lower the barriers -not raise them- when it comes to getting data protection in place. You can connect as many client-side applications to the key server as you wish.
Q: How do you keep system administrators from getting at the data and the keys at the same time.
A: Tasks such as the management of the server, putting it on the network, establishing system logging options, setting the timeservers - all network administration processes - are segmented from the actual management of the encryption keys. Good security practice says that those should be different people engaging in those activities. We provide completely different interfaces to simplify separation of duties.
If you are using our Cloud HSM environment, it is not administered, managed, or accessed by the cloud provider nor by Townsend Security. You have exclusive access and control over your encryption key managers. We even provide a path if you wish to take the encryption key manager out of the cloud environment and install it in your own data center. We believe strongly that a security device should be exclusively under your control, not under the control or management of the cloud provider.
I encourage you to download the recording of the entire webinar and Q&A session:
Townsend Security, an industry leader in data security and encryption key management, will be exhibiting at the PASS Summit in Charlotte, North Carolina this year on October 15-18. We will feature our FIPS 140-2 compliant encryption key management hardware security module (HSM), along with our new hosting option for managing your encryption keys in the cloud.
Will you be attending PASS this year? The Professional Association of SQL Server (PASS) hosts this summit every year and is the largest conference for SQL users and professionals worldwide. Look for us in booth #322 to learn more about how easy encryption and encryption key management can be with your SQL Server. Whether you are using a legacy version of SQL Server or SQL Server 2012 with Transparent Data Encryption (TDE) and Extensible Key Management (EKM), Alliance Key Manager can manage your encryption keys.
How Alliance Key Manager for SQL Server protects your data:
- Automation of all key management tasks including rotation, retrieval, and generation in a central location
- Uses Microsoft’s Extensible Key Management (EKM) interface to support Transparent Data Encryption (TDE) on SQL Server 2008/2012
- Works with all versions of SQL Server
Key Management Hosted in the Cloud
Townsend Security's new Alliance Key Manager Hosted HSM solution allows customers to own a dedicated key manager HSM in a hosted environment consisting. The solutions consists of a production and high availability (HA) HSM in geographically dispersed data centers under an ITIL-based control environment independently validated for compliance against PCI DSS and SOC frameworks. Unlike other hosted encryption key management offerings, only the customer has administrative and security access to the HSMs.
Encrypting Data in Microsoft SharePoint
Since Microsoft SharePoint runs on top of a SQL Server environment, protecting data in SharePoint is easier than ever. Many SQL administrators are fearful that their users are storing sensitive, unencrypted data in SharePoint, and they rightly should be. Alliance Key Manager for SQL Server can help to secure this data.
Encryption Key Management for SQL Server Enterprise Edition
Alliance Key Manager for SQL Server integrates seamlessly with TDE and EKM technologies to enable automatic encryption in SQL Server 2008/2012 Enterprise Edition and above. Additionally, Alliance Key Manager for SQL Server supports cell level encryption, which allows database administrators to select the columns they wish to encrypt in a database - a benefit for many administrators with larger databases.
Encryption Key Management for SQL Server 2005
Many SQL users are still running earlier editions of SQL Server that don’t support EKM & TDE. However, running older versions of SQL Server does not limit your ability to encrypt data and manage encryption keys! Townsend Security supports cell level encryption for SQL Server 2005.
Alliance Key Manager isn’t exclusive to the Microsoft SQL suite. In fact, our key management server integrates easily into complex, multi platform environments with many types of databases, operating systems, and programming languages. Our encryption key manager can protect data on the IBM i (AS/400), DB2, Oracle, Linux, Windows, and in the cloud.
To learn more, download our white paper "Encryption Key Management for Microsoft SQL Server 2008/2012."
This is in the category of people and organizations you should get to know:
If you are a Windows developer and work with Microsoft SQL Server, you should get to know the SQL Server Worldwide User Group (SSWUG). The web site is sswug.org and has a wealth of information about everything you would want to know about SQL Server. And they are even branching out to other database systems like Oracle and IBM DB2. But the emphasis at SSWUG has been on SQL Server and you will find a large number of articles, blogs, videos and other content on wide variety of topics related to SQL Server.
I’ve had the pleasure of working with Stephen Wynkoop on a number of occasions and really appreciate his depth of knowledge on security topics related to SQL Server. While not defining himself as a security specialist, Stephen brings a seasoned and mature approach to the subject of database security and I am always impressed with his thoughts and perspective.
Recently SSWUG dedicated a section of their web site to “Townsend Security Tips” where they present videos of Stephen and I discussing security topics ranging from securing data with encryption and key management on SQL Server (not just with EKM) to protecting data in the cloud. Additionally, they post a new security segment just about every week on their homepage, so there is always something fresh. Upcoming sessions include meeting evolving compliance regulations and how to make sure your data is secure when you when trusting it to a hosting company. We have a great time recording these videos, and if you haven’t seen any yet, I urge you to check them out.
In addition to the content on the SSWUG website, SSWUG also holds virtual conferences and Summer Camps that are great online resources for developers.
SSWUG - Get to know them!
Going Beyond Compliance Requirements with Encryption Key Management
If you are new at protecting data in Microsoft SQL Server environments, generally compliance regulations are what drive an encryption project. In the past, encryption has had a reputation for being difficult to do, complex, and time consuming, we hope to show you how that has changed.
To start us off, here are a few definitions and acronyms that may help:
- AES – Advanced Encryption Standard – this is the most common standards based encryption that is used to protect data whether that is in SQL Server or any other environment where data-at-rest is protected.
- EKM – Extensible Key Management – within the Microsoft SQL Server environment EKM is a part of the Enterprise edition 2008/2012 and higher
- HSM – Hardware Security Module – the Townsend Security HSM encryption key management product is Alliance Key Manager
- FIPS – Federal Information Processing Standard
- NIST – National Institute of Standards in Technology
Since it wasn’t thought of as something that improved the “Bottom line” by increasing revenue or decreasing expenses, encryption has historically been a project solely driven by the need to meet compliance regulations.
There are a large variety of compliance regulations that most, if not all, businesses fall under. One common misconception about compliance regulations is that they don’t equally apply to both private and public companies. To clarify, these regulations apply to all companies, of all sizes, whether they are privately-held or publicly-owned. For example, if you take credit cards for any reason, you fall under Payment Card Industry - Data Security Standards (PCI-DSS). Other common regulations are:
- HIPAA Data Security & HITECH Act of 2009 which applies to Medical Providers and the healthcare industry.
- GLBA/FFIEC apply to banks, credit unions, credit reporting agencies, and anyone in the financial industry.
- FISMA is for Federal US Government Agencies.
- The Federal Trade Commission (FTC) also gets involved with anyone who issues a privacy statement.
More than 45 states also have their own privacy rules, in addition to the ones listed above, that strongly recommend encryption of any personally identifiable information (PII).
So, beyond compliance with regulations, why should you care about encryption… and what is it anyways? First of all, your customers, clients, and suppliers all expect you to protect their sensitive data. Hackers and data thieves are targeting mid-sized companies because, as larger companies get better at securing sensitive information, the hackers see smaller companies as better targets. Financial fraud and data breaches become more common in those businesses that might not be as prepared without the resources to have an internal security team. Data loss can have a big impact on a company's reputation as well as their financial health.
AES encryption is a mathematical formula for protecting data. It is based on a proven, well-known algorithm and standards published by NIST. But since that formula is a open and vetted standard use, it is not the mathematical algorithm that is the big secret. It is what happens with the “Key” that locks and unlocks the data that all the fuss is about.
Key management is so important because the encryption keys are THE secret that must be protected. Without access to the key, a hacker that accesses encrypted data has no way to read it. Industry standards and best practices for encryption key management, as well as compliance regulations that require proper encryption key management, all state that storing encryption keys on the server with the protected data is a poor security practice. Encryption keys are unique and cryptographically secure, and once created, protecting the key is the core practice that will protect the sensitive data. It will not be defensible in the event of a data breach if the keys were stored in the same server as the data. (Akin to leaving the key to your house in the door lock and being surprised that someone has entered uninvited!)
Our solutions help Microsoft SQL Server customers really protect their data. Alliance Key Manager, our encryption key management hardware security module (HSM), is FIPS 140-2 certiied. This means it meets Federal standards that private enterprises expect around key management. We provide encryption key management solutions for every version and edition of SQL Server starting with SQL Server 2005.
Please join our founder and data security expert, Patrick Townsend, in this 30-minute webinar that will cover encryption and key management best practices with Microsoft SQL Server!
As always, your comments and feedback are appreciated!
In Microsoft SQL Server 2008/2012 Enterprise edition users can enable Extensible Key Management (EKM) and use either TDE or cell level encryption to encrypt their sensitive data and to be selective about the data they encrypt. EKM is an architecture that allows users to incorporate a third-party* encryption key management hardware security module (HSM) in order to truly secure their data using key management best practices and meet compliance regulations.
*Townsend Security is a Microsoft Silver partner and provider of encryption key management HSMs for Microsoft SQL Server, Microsoft SharePoint, Windows, and Microsoft Azure.
Users select from one of the two methods of encryption available for the Microsoft SQL Server 2008/2012 Enterprise Edition and above:
1) Transparent Data Encryption (TDE): TDE encrypts the entire database and temporary files within that space with no additional programming.
On earlier versions of SQL Server deploying encryption had been a much larger and more complicated programming project. With 2008/2012 Enterprise edition, TDE can be implemented fully without any programing at all. Once your administrator has DBA administrative rights, he or she can implement TDE through a straightforward process that requires no changes to coding, queries, or applications. TDE is a favored way to rapidly encrypt data and works well for small or medium sized databases because of its speed and ease of deployment.
2) Cell Level Encryption: Cell Level Encryption allows database administrators to select the columns they wish to encrypt in a database - a benefit for many administrators with larger databases; however, this process takes a little bit more effort to set up.
If you are leveraging EKM and using an external encryption key manager, the database administrator can encrypt data in the column (cell level) by adding a modifier on a particular fetch or update to the database. However, administrators will need to make small changes to their databases to enable their encryption key manager to do this. This is not a complicated step, however, and your encryption key management vendor should be able to help you through this. Cell level encryption works well for large databases where performance impacts must be kept to a minimum and only certain data needs to be encrypted.
Here is a very straightforward YouTube demonstration video where you can see just how easily TDE is set up.
Setting Up TDE & EKM on SQL Server 2008 / 2012 for Compliance
For a more in-depth look, we have compiled a selection of resources (webinar, white paper, podcast) that can provide additional information:
As always, we welcome your comments and question.
When protecting your data in SQL Server, you need to be as informed as the hackers!
Whether you are the CEO or the database administrator of your company, you need to be aware of what data you are storing and the different compliance regulations that require encryption and key management.
Having a data breach can often go undetected for quite some time, but when it happens (and these days it is “when” not “if”) it can cause some serious issues for your company and your customers!
While “the bad guys” get more creative every day, being aware of their tactics and following security best practices can slow them down and hopefully thwart their attempts from being successful. Research and “post-data breach” studies have shown that 80% of data breaches happen with a fairly low-tech “old school” type of attack known as SQL injection. In fact, Injection is #1 on the “2013 Top 10 List” of simple security problems from OWASP (the Open Web Application Security Project).
While not the only method, SQL injections are still one of the most common ways of attacking web services by sending malicious SQL code in parameter fields, with the intent that the server will execute the code. When designing web applications or internal applications you need to remain aware of SQL injection opportunities beyond just the systems securing credit card data. So many people think “we don’t have that problem.” However, if your application is on the internet… you do. Features such as login pages, support or product request forms, shopping carts are all examples of web applications that can make your databases vulnerable. Hackers can gain entry through these other areas of your company website and navigate their way to more valuable data. Once inside your database, they can retrieve or delete sensitive information such as credit card numbers, clients personal information, or company records. Safeguards such as encryption and key management can help prevent those losses only if they are in place.
Good practices to prevent or mitigate attacks like SQL injection and the loss of unencrypted data :
- Analyze your website and web applications for vulnerabilities.
- Look for it in your system logs, make monitoring a priority.
- and remember, internal apps are just as susceptible as public apps.
From a best practice point of view, as well as a regulatory compliance view, encrypting your data is a fundamental security step for any system. So even if the information is “retrieved”, it isn’t in a readable format and the hackers won’t be able to use it! While data encryption used to seem like a daunting task, that is no longer the case. SQL Server 2008/2012 Enterprise Edition and above includes TDE offerings that allows for encryption without application changes. You can now deploy key management that is easy to use and affordable with Alliance Key Manager, our FIPS 140-2 certified encryption key management HSM.
Just keep in mind that the single biggest data security issue is failure to protect the encryption key. Always keep your keys off the server and out of the system that holds your encrypted data. Think of it like the lock on your front door… you wouldn’t lock up your house and then tape the key next to the handle… would you?
We would like to offer you a complimentary copy of our eBook: “Encryption Key Management Simplified”, which is a fundamentals guide for both IT administrators and business executives alike.
As always, your comments and questions are welcome!
With the emergence of data security standards, encryption and key management have become a necessity for most companies storing or transferring sensitive data such as credit card numbers, patient data, social security numbers, and other personally identifiable information (PII).
Transparent Data Encryption (TDE) on Microsoft SQL Server 2008, 2008 R2, and 2012, allows automatic encryption on these editions of SQL Server without application changes. With newly available SQL Server encryption capabilities, encryption key management--a critical step to securing your data--is done easily on SQL Server with extensible key management (EKM). EKM allows customers to choose a third-party encryption key management hardware security module (HSM) and integrate that HSM easily into their SQL database.
Without an encryption key management HSM, SQL Server users are essentially leaving the keys to their data underneath their welcome mat!
Three things to remember for following security best practices:
# 3 – SQL Server Encryption isn’t as imposing as it sounds…
- Compliance regulations drive the need for encryption and require that you protect the encryption keys apart from the encrypted data storage.
- An encryption algorithm is simply a mathematical formula that protects data. The critical element is the way the “Key” to that formula (the encryption key) is managed.
- HSMs like Alliance Key Manager create, manage, and protect encryption keys through the entire lifecycle and deliver them securely when they are needed.
- Alliance Key Manager is a quick, efficient, and compliant solution that is easy to implement with our “Key Connection for SQL Server” EKM provider software. Based on FIPS (Federal Information Processing Standard) 140-2 certified technology, it is easy to implement, deploy, and configure with “out of the box” integration with SQL Server.
- Townsend Security is Microsoft Silver partner and Alliance Key Manager works with all versions of Microsoft SQL Server including SQL Server 2005. Additionally, Alliance Key Manager allows you to protect sensitive data stored in Microsoft SharePoint and Microsoft Azure.
#2 - You are required to protect data by government and industry created regulations…
- PCI-DSS (Payment Card Industry – Data Security Standard) for merchants
- HIPAA/HITECH (Health Insurance Portability and Accountability Act)/(Health Information Technology for Economic and Clinical Health) for medical providers
- GLBA/FFIEC (Gramm-Leach-Bliley Act)/(Federal Financial Institutions Examination Council) for the financial industry
- FISMA (Federal Information Security Management Act) for US Government agencies
#1 - Customers expect their data to be protected!
- PCI-DSS is required for anyone who takes credit cards.
- While expectations for data protection in the medical and financial industries are wide-spread, and easily understood, compliance regulations affect business and organizations of all sizes.
- Beyond the expectations for privacy, and the laws that require it, the consequences of a data breach or data loss can be substantial.
- Small to mid-sized companies can be an easy target for data thieves, resulting in costly losses to their business and reputation.
We have resources to share with you about SQL Server Encryption and how to best secure your data. Please click the button below to access these informative downloads!
As always, we welcome your comments and questions!
Almost every organization has at least one application built on Microsoft’s SQL Server database. Whether you build an application in-house using Microsoft’s development tools or you deploy a software package from a software vendor, chances are that your organizations has one or more SQL Server databases to help you manage information.
Today it is almost impossible to run a business without handling sensitive information and storing storing data such as customer names, credit card numbers, bank account numbers, passwords, email addresses, or other personally identifiable information (PII) or private health information (PHI) in your SQL Server database. If your organization must meet data security regulations such as PCI-DSS, HIPAA/HITECH, or GLBA/FFIEC, you probably already know that this data must be encrypted in order to protect your customers and prevent data loss in the event of a data breach.
What you may not know is that in order to truly protect your data, you must manage your encryption keys in adherence to key management best practices such as dual control and separation of duties using an external hardware security module (HSM). Your company will only be able to avoid data breach notification if you are using these best practices.
The good news is that in its most recent release, SQL Server 2008/2012 comes equipped with transparent data encryption (TDE) and extensible key management (EKM) to make encryption and key management using a third-party key manager easier than ever. Older versions of SQL Server can also be easily encrypted using different tactics, and you can manage those encryption keys just as easily on an HSM as well.
If you’re currently looking into encrypting your SQL Server database or deploying a key management system, you may be concerned about how to protect your data depending on the version, code, and language used to build your database. To help ease your worries, here are 4 ways to encrypt your SQL Server database and protect your encryption keys:
- Since SQL Server 2008 Microsoft has supported automatic encryption with TDE and cell level encryption for Enterprise Edition users and above. Without any programming you can encrypt the SQL Server database or an individual column, and store the keys on an encryption key management HSM.
- If you have an older version of SQL Server, or you have SQL Server Standard Edition or Web Edition, you don’t have access to TDE. But you can still automate encryption: Through the strategic use of SQL Views and Triggers, you can automate encryption of sensitive data on your SQL Server without extensive program modifications, and still use a secure key management HSM to protect the encryption keys.
- Your developers might have written custom application code to implement your SQL Server database. But SQL Server encryption and key management is still within your reach. A good key management vendor should supply you with software libraries that easily add into your applications and implement SQL Server encryption.
- You might have a SQL Server database, but not be using Microsoft programming languages. Perhaps your applications are written in Java, Perl, or PHP. Again, it is simple to deploy software libraries that encrypt the SQL Server data and which store the encryption keys on a key server HSM.
SQL Server encryption and good key management is not difficult to achieve. Although key management has a reputation for being difficult and costly, today key management for SQL Server is cost-effective, easy, has little to no performance impact, will get your company in compliance, and will keep your organization out of the headlines by helping to prevent a data breach.
To learn more about key management for SQL Server, download the White Paper, “Encryption Key Management for Microsoft SQL Server 2008/2012.”
Since it's release in 2001, Microsoft SharePoint has quickly become one of the most widely used applications for document storage and collaboration.
SharePoint originally stored and organized documents and other critical information about those documents in rows and columns. However, as the use of SharePoint began to quickly grow, administrators
began to notice that the huge number and size of the documents being stored began to impact the performance of SharePoint, slowing down the application until it was fairly unusable. To rectify this issue Remote Blob Storage (RBS) was introduced to store the documents themselves outside of the SharePoint database so that the size of the documents wouldn't impact SharePoint performance. Now, when a SharePoint administrator starts to see performance impact from documents stored in SharePoint, they can store the files themselves separately, and SharePoint talks to the remote server in order to retrieve the files.
Now that SharePoint is so widely used, protecting data stored in SharePoint has become a big issue. Many companies use SharePoint to track customers, retail orders, personal health information, and other personally identifiable information (PII) that most industries (PCI-DSS, HIPAA/HITECH, GLBA/FFIEC, etc.) and many state laws mandate the protection of. Typically these regulations mandate the protection of this data using encryption and encryption key management.
The good news is that encrypting data in SharePoint is pretty easy, and it's often only a two-step process. SharePoint administrators must:
- Encrypt the SQL Server database SharePoint runs on
- Encrypt the Remote Blob Storage (RBS) used to store documents.
Encrypting SharePoint on SQL Server is easy with transparent data encryption (TDE) for SQL Server 2008/2008 R2/2012. Extensible key management (EKM) also allows admins to manage encryption keys and meet compliance regulations using an external third-party encryption key management hardware security module (HSM).
Townsend Security offers FIPS 140-2 compliant encryption key management system for Microsoft SharePoint to help you protect SharePoint and meet compliance. To learn more about securing data in SharePoint, check out our podcast, “Securing SharePoint with Encryption & Key Management.”
I often speak with organizations that need to employ encryption and external key management for multiple relational databases they are using to store encrypted data. Often this is a combination of Oracle and Microsoft SQL Server databases.
Transparent Data Encryption (TDE) is used within both the Microsoft SQL Server and Oracle Database universes to provide encryption services at the tablespace level. Many companies employ TDE and external encryption key management to meet the concept of "Separation of Duties" as required by PCI DSS and other compliance regulations. Also, TDE is often easier to implement than column level encryption that may require programming changes to your application layer.
In Microsoft's SQL Server Enterprise edition 2008/2012 you have access to Extensible Key Management (EKM). When EKM is enabled, SQL Server users can use encryption keys stored on external key managers, as opposed to accessing local key stores, which doesn't line up with compliance requirements. Also, another benefit of using EKM is that you can easily take advantage of TDE as your database encryption approach.
If you're running versions of Microsoft SQL server that don’t support EKM, don't worry. You can still take advantage of the added features and security of using an external key manager with our encryption key management HSM, Alliance Key Manager (AKM). AKM fully supports the entire Microsoft SQL Server product line. You’ll just have make some programming changes to your application code to perform the necessary API calls to the key manager and you'll be set up to do key retrieval. To help you with the process, we provide sample code and the .Net key retrieval assemblies to add to your project. Additionally, we have C# and VBNET sample code that shows how to retrieve a key from the key server.
Much like Microsoft SQL Server, in the land of Oracle you need to be running Oracle Enterprise Edition with the Advanced Security option. This can often be a pricey upgrade and I find that quite a few organizations would rather do column level encryption due to this fact. AKM fully supports the path to column level encryption within the Oracle 10g and 11g environments. Again your approach will include making coding changes to your application layer to perform key retrieval from AKM. To help you with this on the Oracle front we provide some PL/SQL sample code for you to work from.
For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.