Security

As always, our first goal is to make analytics via API powerful but simple. We want to make your life as easy as possible. Like any good service, Keen takes security seriously. Sometimes, there’s a direct conflict between ease-of-use and security. Effectively securing an API almost always means making that API harder to use.

There’s not a lot of room for compromise here. A system is either following cryptographic best practices or it’s not. We follow best practices. That being said, we want you to be happy. Please reach out if you’d like to discuss security in more detail.

Security FAQ

Do I have to store my data in Keen’s cloud to run analysis on my data?

Keen’s self-service compute and embedding capabilities require you to store your data in our cloud. Keen compute isn’t the only way to make use of your data. We also offer services that stream your data directly to Amazon S3, giving you additional optionality for how you use and access your data.

Where is data stored?

Keen data is stored in AWS cloud servers. Currently, we use data centers in the US, but we may expand this at any time.

Is the data encrypted at transfer on rest?

Traffic between clients and Keen is encrypted through TLS.

Data is encrypted at rest in order to support the demands of ad-hoc computation response time. Traffic between our internal services is not encrypted, but is secured by virtue of being within our VPC (virtual private network).

Compliance

Privacy Shield

Keen meets the criteria for Privacy Shield certification. Contact Us for more details if Privacy Shield is important to your business.

GDPR

Keen welcomes the GDPR. It protects citizens’ fundamental right to privacy and the protection of personal data. It will raise the bar for data protection, security, and compliance across our industry. Keen is committed to meeting the requirements of GDPR. Contact Us for more details if GDPR is important to your business.

API Security Features

Encrypted Communication

All HTTP requests to Keen should be done over SSL. SSL is the industry standard for securing HTTP traffic. Our website defaults to HTTPS and we do not recommend non-SSL (HTTP) traffic to our API.

SSL secures everything in the HTTP payload, which includes potentially sensitive information (like your project ID), and definitely sensitive information (like your API Key).

API Keys

Keen supports a variety of models for accessing and security data via our API.

  • Master Key - The most powerful API key. It can be used to authenticate for any API call. It is required to perform administrative functions, such as deleting data.
  • Write Key - An API key specifically for writing data. Any API request that writes data to Keen can use this.
  • Read Key - An API key for querying and extracting data. Used to run analyses and extract data from Keen.
  • Access Keys - These are custom keys that you define to give access to subsets of data and operations on that data.

Protecting Your API Key

Your Keen Master Key, along with your username and password, is the holy grail of Keen. If you have that, you have access to all Keen API features. This includes querying data, changing data, and even deleting data.

Never give your Master Key to anybody. Keen team members will never ask you for it. And you should never expose the Master Key to your users. So, just to be clear - be careful with it! :)

Should you accidentally expose one of your keys, Keen gives you the ability to disable it immediately and generate a new key.

Client Security

Keen is used prominently in many clients (iOS, Android, Mobile Web, Desktop Web, etc.). Just like other analytics services, you embed a snippet of code into your application or site, and that snippet includes some identification about your account. At Keen, that’s your Project ID.

An unfortunate truth about client security is that any code embedded into a client is inherently not secure. The source can be viewed, decompiled, or unobfuscated. Or the binary itself can be analyzed. What this means is that you should NEVER embed secure credentials in your clients.

Keen breaks down its access paths into two modes - writing and reading. Writing, or sending events, requires your Project ID and a Write Key. Reading, or doing analyses, requires your Project ID and a Read Key. If you’re only using one of our clients to add events, don’t include your Read Key. And if you’re only using a client to do analyses, don’t include your Write Key.

The important thing here is that the Master API Key is NEVER required for the most common use cases. You should never embed your Master API Key in a client.

Server Security

Unlike a client, you can actually secure your servers (go you!). This means you’re free to embed your Master API Key in your source code or configuration. One of the easiest ways to make sure your API Key never gets leaked is to proxy all API requests between your clients and Keen servers through your own servers. But maintaining a proxy is annoying and can get expensive as you grow (not to mention it’s a potential single point of failure). We have a solution to that.

Protecting Your Data

Let’s say you want to use the Keen JavaScript SDK both to collect data from, and give charts to, your users. You’ll have the following security concerns:

  • How do I prevent somebody from sending events to Keen?
  • How do I prevent a customer from performing administrative operations in Keen?
  • How do I make sure customer A can’t read customer B’s data?

Securing Writes

There’s no way to both allow clients to send data to Keen and prevent a malicious user of a client from sending bad data. This is an unfortunate reality. Google Analytics, Flurry, KissMetrics, etc., all have this problem.

The bright side of this is that Keen requires a Write Key to write data. And we can disable a write key if it’s being misused in some way. What this means for you is that you have more control over how data is being written to your Keen project.

Securing Administrative Operations

At Keen, only requests authenticated using your Master API Key can perform administrative operations (things like deleting data, creating new saved queries, etc.). So the simple answer is to NEVER give your Master API Key to anybody and to never expose it in a client. Because sending data to Keen doesn’t require your Master API Key, this is usually simple. But what if you also want to let your clients read data?

Securing Queries

Keen queries can only be done by authenticated users. A request can be authenticated by two mechanisms:

  1. Your API Key. This is appropriate if your requests are issued from your server. Otherwise you’ll be exposing your API Key, which is bad!

  2. Keen leans on industry standards. To make security easier for our users, we’ve automatically generated both a Write and a Read Key. They’re listed on your project details page right next to your API Key. Feel free to use these.

  3. An Access Key. This is a special API key that can be programmatically generated via API request to Keen. It applies filters you define to any query that is run while using that particular Access Key. This is helpful if you’re trying to expose data to your users, but you don’t want them to have access to anyone else’s data. The process of generating an Access Key is below.

Access Keys and Security

When To Generate an Access Key

If you’re serving analytics to your users, you’ll want to generate an Access Key. It is best practice to create this Access Key once as part of your customer’s onboarding, aka when a user/account is created in your application. To help you keep track of Access Keys you created, you can check the Access Key Table in our User Interface or retrieve a list via our API.

For a more in-depth view of when it may be appropriate to create an Access Key see our Access Key Guide.

Generating an Access Key

  1. Use the Keen to generate an Access Key with the permissions you want. This can be done via the Access Keys UI under Settings, or via our API. A unique key in string format will be generated.

  2. Take that string and use it in place of your API Key.

  3. Keen will see the permissions and options defined in your custom Access Key. If you defined any filters, we will automatically apply your filters defined in your Access Key to your queries. So, for example, you can create customer-specific keys that automatically add the customer filter to all read analyses.

Notes on Access Keys

Depending on how you generate it, an Access Key can either do writes or reads (or both). It can never do admin operations (like deleting data). Access is determined by the value you include for the “permitted” property. Its value should be a list of strings. Valid values for writing are: “writes”. Valid values for different types of reads are: “queries”, “saved_queries”, “cached_queries”, “datasets”, and lastly, “schema” (which lists project metadata). For a more details on Access Keys see our Access Key Guide.

At the end of the day, the ONLY thing an Access Key can do is what you tell it to do. But it can’t delete data and it can’t perform any admin requests. So rest easy knowing that giving your user an Access Key is secure.