By Mark O’Neill
Much lip service is paid to protecting information in the Cloud, but the reality is often seat-of-the-pants Cloud security. Most organizations use some form of API keys to access their cloud services. Protection of these API keys is vital. This blog post will explore the issues at play when protecting API keys, and make some recommended solutions.
In 2011, the sensitivity of API Keys will start to be realized, and organizations will better understand the need to protect these keys at all costs. After all, API keys are directly linked to access to sensitive information in the cloud (like email, sales leads, or shared documents) and pay-as-you-use Cloud services. As such, if an organization condones the casual management of API keys they are at risk of: 1) unauthorized individuals using the keys to access confidential information and 2) the possibility of huge credit card bills for unapproved access to pay-as-you-use Cloud services.
In effect, easily accessed API keys means anyone can use them and run up huge bills on virtual machines. This is akin to having access to someone’s credit card and making unauthorized purchases.
APIs
Let’s take a look at APIs. As you know, many Cloud services are accessed using simple REST Web Services interfaces. These are commonly called APIs, since they are similar in concept to the more heavyweight C++ or Visual Basis APIs of old, though they are much easier to leverage from a Web page or from a mobile phone, hence their increasing ubiquity. In a nutshell, API Keys are used to access these Cloud services. As Daryl Plummer of Gartner noted in his blog: “The cloud has made the need for integrating between services (someone told me, “if you’re over 30 you call it an ‘API’, and if you are under 30 you call it a ‘service’”) more evident than ever. Companies want to connect from on-premises apps to cloud services and from cloud services to cloud services. And, all of these connections need to be secure and governed for performance.”
As such, it’s clear that API keys control access to the Cloud service’s crown jewels, yet they are often emailed around an organization without due regard to their sensitivity, or stored on file servers accessed by many people. For example, if an organization is using a SaaS offering, such as Gmail for its employees, they usually get an API key from Google to enable single sign-on. This API key is only valid for the organization and allows employees to sign-in and access company email. You can read more about the importance of API keys for single sign-on in my earlier blog titled “Extend the enterprise into the cloud with single sign-on to cloud based services.”
How Are API Keys Protected?
API Keys must be protected just like passwords and private keys are protected. This means that they should not be stored as files on the file system, or baked into non-obfuscated applications that can be analyzed relatively easily. In the case of a Cloud Service Broker, API keys are stored encrypted, and when a Hardware Security Module (HSM) is used, this provides the option of storing the API keys on hardware, since a number of HSM vendors including: Sophos-Utimaco, nCipher Thales, Safenet and Bull among others, now support the storage of material other than only RSA/DSA keys. The secure storage of API keys means that operations staff can apply a policy to their key usage. It also means that regulatory criteria related to privacy and protection of critical communications (for later legal “discovery” if mandated) are met.
Broker Model for Protecting API Keys
The following are some common approaches to handling API keys with recommended solutions:
- Developers Emailing API Keys: organizations often email API keys to developers who copy and paste them into code. This casual practice is rife with security issues and should be avoided. Additionally, if a developer bakes the API keys into code, a request for a new key requires a code change resulting in extra work.
- Configuration Files: another common scenario is where a developer puts an API key into a configuration file on the system where it can be easily discovered. As such, people should think of API keys as the equivalent of private SSL keys that should be handled in a secure fashion. In fact, if API keys get into the wrong hands they are actually more dangerous than private SSL keys as they are very actionable. For example, if someone uses an organization’s API keys, the organization gets the bill. One solution to this scenario is to have the keys in a network infrastructure that is built for security. This would involve cloud service broker architecture with the broker product managing the API keys.
- Inventory of Keys: a way to avoid issues with managing API keys is the implementation of an explicit security policy regarding these keys. Ideally, this should come under the control of the Corporate Security Policy with a clear focus on governance and accountability. The foundation of this approach is to keep an inventory of API keys. Despite the benefits of such an inventory, many organizations continue to adopt an ad hoc approach to keeping track of API keys.
Some of the key questions organizations should ask when developing an inventory of API keys are:
- What keys are being used and for what purposes?
- Who is the contact person responsible for specific keys?
- Is there an expiry plan in response to the expiry date on the usage of keys? How will notification happen? If there is no clear plan on how to handle expired API keys, it can cause pandemonium when a password expires.
The inventory could be managed on a home-grown encrypted excel spreadsheet or database or via other more specific off-the-shelf products. The disadvantage of the home-grown approach is the amount of time required to manage the spreadsheet or database and the possibility of human error. An alternate approach is to leverage the capabilities of an off-the-shelf product such as a cloud service broker. In addition to providing other services, a broker allows an organization to easily view critical information about API keys, including identifying who is responsible for them, as well as providing information on how they are being used and the expiry dates.
4. Encrypted File Storage: One of the more potentially dangerous options is when a developer tries to implement their own security for API keys. For example, the developer understands that the API keys have to be protected and chooses to store the keys in a difficult to find spot – sometimes by using an encryption algorithm and hiding it in files or a registry which people would not typically access. Someone will inevitably find out about this “secret” hiding spot and before long this information is publicized throughout an organization. This classic mistake really highlights the old adage that security through obscurity is no security at all.
In summary, as organizations increasingly access Cloud services, it is clear the casual use and sharing of API keys is an accident waiting to happen. As such, regardless of how an organization chooses to manage API keys, either using a home grown approach or off-the shelf product, the critical goal is to safeguard the access and usage of these keys.
I would encourage CIOs and CSOs to recognize API keys as first class citizens of security policies similar to SSL private keys. I would also advise anyone dealing with API keys to think of them as a sensitive resource to be protected as they provide access to sensitive information and access to pay-as-you-use Cloud services. In summary, effective management of API keys could enhance an organization’s Cloud security and avoid unauthorized credit card charges for running virtual machines, whereas slack management would likely result in leakage of sensitive information in addition to providing unrestricted access to pay-as-you-go Cloud Services – courtesy of the organization’s credit card.
Mark O’Neill is the chief technology officer at Vordel. As CTO, he oversees the development of Vordel’s technical development strategy for the delivery of high-performance Cloud Computing and SOA management solutions to Fortune 500 companies and Governments worldwide. Mark is author of the book, Web Services Security, and a contributor to Hardening Network Security, both published by Osborne-McGrawHill. Mark is also a representative of the Cloud Security Alliance, where he is a member of the Identity Management advisory panel.