"This article was originally posted on Pantheon’s blog. Pantheon is a website management platform for Drupal and WordPress."
Let’s back up a few steps. Why are there keys and where are they in the first place?
Private API keys are actually used frequently within a CMS by services like Authorize.net, PayPal, MailChimp, etc., and stored in the clear. If your site gets hacked, so does access to the services that you have integrated into your site. For example, if your Amazon S3 API key were in your stolen database, hackers would have access to your entire offsite S3 storage. Let’s take MailChimp, for example: If your MailChimp API key becomes compromised, hackers could send out emails as if they appeared from you, leaving customers surprised to learn that you just got into selling Viagra.
In Drupal, for example, there are several modules (Encrypt, Field Encryption, Encrypted Files, etc.) that allow you to encrypt various types of data. This is a very necessary step to keeping your data secure, however what happens to the key to unlock that data? Typically, developers will store their encryption keys locally in either a file protected on the server, in the database, or in Drupal’s settings file. Not very secure places. Further, for companies who fall under data security compliance requirements like HIPAA, FISMA, or PCI DSS, key management requirements are pretty clearly spelled out, and these default methods don’t even come close to being sufficient. Essentially, the compliance requirements all say the same thing: encryption keys should never reside in the same environment or server as the encrypted data. This is a technical way of saying, don’t leave your key under the doormat a hacker walks in over.
Unfortunately in WordPress, there are isolated solutions, but no plugin that provides and manages the encryption process. The team working on the Drupal encryption modules are also working to bring the same functionality to WordPress.
Now that we have established storing sensitive keys within the CMS is not secure, what should we do with them?
Keys need to be stored outside of the CMS and developers need to consider how they’ll manage all of these keys. Most encryption modules are designed to create a new key each time the encrypted data is accessed and re-encrypted. As you can imagine, versions of keys add up quickly and managing them is quite a task—not something that you’d want to do manually (luckily your server can’t put a sticky note of keys on its hard-drive).
There are solutions and services designed specifically for key management that can run on a wide variety of platforms ranging from in the cloud, to VMware, to a physical hardware security module (HSM). These solutions can safeguard your API keys, as well as manage encryption keys through the entire lifecycle—from creation to destruction. Additionally, an external key manager will allow for:
Key naming and versioning
Key change and rotation
Secure key retrieval
Key mirroring
Key import and export
Password and passphrase protection
User and group control for key access
Luckily, for Drupal users, there is a super easy way to integrate external key management (and follow security best practices). This can happen by way of the “Key” module. Key acts as a central routing API for keys and is easily extended to integrate with your key management vendor of choice.
These modules act as the bridge between the various encryption/API modules and an external key manager. They give site administrators the ability to define how keys are stored, which provides an increased level of security and allows sites to meet compliance requirements and security best practices. With these modules installed, users no longer need to settle for storing their keys in insecure places.
While there currently isn’t a Key equivalent for WordPress, efforts are being made to remedy this. By early 2016, we can expect to see great progress in the way of managing encryption and API keys in via a plugin similar to that in the Drupal environment. For now, WordPress developers need to rely on an external service such asLockr to secure these keys.
There are three important questions that need to be asked when considering your key management strategy:
Do I want to manage the keys myself or use a service?
Do I need to meet any compliance requirements?
What is my budget?
Your budget and needs can play a large part in determining which route you take. With a low entry price point, a multi-tenant managed key service (where your keys are stored alongside other companies’ keys on the same key manager) is a great option. These services typically operate in the cloud and allow businesses to remove their keys from under the “Welcome” mat and store them in a more secure environment. As businesses or security needs grow, managed key services can easily scale and migrate users to a dedicated, FIPS 140-2 compliant key manager that can help them meet compliance (PCI DSS, FISMA, etc.).
For users who feel more comfortable with a hands-on approach—or don’t trust anyone but themselves with their keys)—a dedicated and self-managed option may be right for them. Dedicated key managers are available virtually (AWS, Azure, VMware) or physically as a Cloud HSM or HSM, and have a wide variety of licensing options.
By now the choice should be fairly obvious. Protecting keys is an important aspect of a strong security posture. As the headlines show, data breaches are a reality—regardless of the size of your business. They can happen as a result of a hacker or disgruntled employee. Properly protecting API and encryption keys is a very easy way to manage the risk and severity of a data breach.
Townsend Security’s dedicated Alliance Key Manager is in use by over 3,000 customers worldwide and is the only dedicated key manager with Drupal integrations. Cellar Door Media also recently launched Lockr, a managed key service for Drupal and WordPress that’s free during development, and once deployed to a site, pricing starts at $30 per month. Lockr also offers managed dedicated key service for enterprise customers.