Security Mechanism For Telemetry API
This page describes the mechanism and plan to implement security on the Telemetry API
Motivation
The telemetry API is a service used by several number of products such as:
RapidScan
VBUC
SnowConvert (all "flavors")
SnowPark
These products are widely used and receive many daily executions. That’s why we have to ensure that only trusted clients can execute request on the Telemetry API. To prevent DoS, DDos attacks and even to prevent fake data that make “noise” in our measurements.
Security Mechanism
Backwards Compatibility Assurance
As mentioned before, those product are actually used by a large number of clients (That would be awesome to mention the exact amount to the date) so we can not just implement a new mechanism of security without think in the compatibility of those Desktop App or services that can not be easily updated to consume the new version of the Telemetry API with the new security method implemented.
Security Methods Proposals
API KEY
A good way to ensure security in our Telemetry API could be by implementing an API Key security layer. This would help us to:
Avoid anonymous traffic.
Have more control in the number of calls made to our API.
Identify usage patterns.
However implementing an API key would cause backward compatibility conflicts to those projects who can’t request an API key.
To solve this we propose to create a new Endpoints secured by the API key, but keep the old ones to allow those trusted projects who already make calls to the API and can not request an API Key.
It is important to point out we need to define a expiration time for each Key and have at least two API Keys. We need at least two key to use the other one when the first one expired and immediately do the request to substitute the expired key.
In this way we will be making a rotation, improving security in case of one key is stolen.
Advantages
Block anonymous traffic and only allows trusted clients.
Can help us to limit the rate of requests to the API.
Improve protection to DoS and DDoS attacks.
Reduce the amount of possible noisy data.
Disadvantages
If a API Key is stolen it would give unlimited access to all the permits associated to that API Key.
We can’t notice if an API Key was stolen or not.
We create a backdoor by keeping the old endpoints.
We can afford the risk of keep the old endpoints because if a malicious user can find out our endpoint, he had to looked in the source code of a project. And if this happens, the endpoint would be the less of our problems.
Best Practices to implement an API Key
Must be a random non-guessable string.
Must contain alphanumeric and special characters.
We must store it as a hashed value within our database.
Limit requests rate by API Keys.
Conclusions
So the best approach to implement the security method in the Telemetry API taking in consideration the low severity in case of a leak would be the API Key method. So the worst scenario would be an malicious user who stole the API Key tries a DoS or DDoS. And in that case we could manage that situation by revoking the keys.
Summarizing we create new endpoints but keep the old ones to ensure backwards compatibility and stablish at least two API Keys and a expiration time for each one, to do rotation and prevent give undefined access to a malicious user with an API Key stolen.
Last updated