Key Management R Hard
(Especially when your customers want to do it.)
((And particularly when only some of them want to do it!))
Photo by Samantha Lam on Unsplash
If you are a B2B SaaS company, chances are good that you are fielding an increasing number of questions from customers and prospective customers about how you protect their data. And if you can tell them a good story about the encryption you offer for their data, you’ve probably gotten some inquiries about whether you allow them to manage their own keys. This capability, often called Customer Managed Keys (CMK) or Bring Your Own Keys (BYOK), is gaining interest as companies become more focused on keeping control of their, and their customers’, sensitive data. Maybe they are doing business with people in the EU and are looking at GDPR requirements and some of the Schrems concerns, or they are disturbed by the rising tide of data breach reports. Whatever the reason, the increasing focus on better data security is a big plus in my view.
IronCore Labs provides a toolkit and services, in our SaaS Shield offering, to help companies easily add CMK to their products. Our initial concept was that SaaS providers could use this to create a premium offering that they could upsell to their largest and most security-conscious customers. We built a user interface that the service provider uses to manage the tenants that have customer managed keys enabled, and an interface that each tenant’s administrators use to manage their own keys that will be used by the vendor.
This seems to work well if the number of tenants that use the feature is not too large and is relatively stable. However, it became apparent after talking to some providers about using the product that there were some drawbacks to assuming that only a portion of their tenants would actually take control of the keys used to protect their data. Pieces of the provider’s application that deal with sensitive data do need to be updated to use the IronCore SDKs to protect the data; having separate code paths in the application for customers with the encryption feature enabled and those that do not is definitely not ideal. It is also advantageous to be able to tell all your customers that you protect their data with application level encryption, even if only some of them decide to manage their own keys.
Obviously, this introduces some new challenges - using the IronCore SDKs to protect sensitive data with application level encryption requires you to identify a tenant for each access of protected data. If you don’t want to put separate branches in all your applications to handle the “has keys” and “doesn’t have keys” cases, it might be tempting as a service provider to just set up a single “tenant” as a catch-all for all tenants that don’t manage their own keys. Once you create keys for that tenant, at least everything is encrypted in the app. At first glance, that would work, but it’s a pretty short-sighted approach; when one of your tenants decides to start managing their own keys, after you rejoice on the upsell, you will realize that you have some of their data encrypted with the catch-all key and some encrypted with their new key. Good luck sorting that out when they want to read some data!
To facilitate providing keys for all customers in a usable way, we added the ability for vendors to create and manage multiple keys on behalf of their customers, and to assign one of those vendor-provided keys to use to encrypt a tenant’s data. This is better than the catch-all approach, because each tenant has a clearly identified set of keys that were used to encrypt their data through time. There isn’t an issue if they want to take control and use their own keys for their data going forward.
In addition to managing keys for existing tenants, we added the ability for service providers to programmatically manage their tenants. Using the UI is fine if you have a few customers, but some service providers have tens or even hundreds of thousands of tenants. We created an interface service, the vendor bridge, which provides REST APIs to perform the management tasks that can be done from the vendor admin UI, including inviting tenants, adding KMS configurations, and assigning configurations to tenants. This vendor bridge runs in the provider’s compute infrastructure, so IronCore never has access to any of the information that is supplied to the service. With these components, vendors can integrate management of tenants in the IronCore SaaS Shield product with their existing customer onboarding and management systems, allowing them to avoid differentiating in their applications between customers that use the advanced key management services built on SaaS Shield and those that don’t. Providers can offer application level encryption and the option to use customer managed keys to all of their customers, which is a good selling point and often a differentiating feature. And their customers (and their customers’ customers) get stronger protection for their data, which is the real goal of all of us at IronCore!
