Easily Protecting API Keys and Achieving ComplianceAnirban Banerjee
In this article we are going to discuss what are API keys, why are they used, the problems arising form their adoption and how to tackle these challenges with a controlled, effective approach.
What is an API Key
API keys are akin to identification cards. For whom you ask, and for what purpose? API keys are meant to be used by automated pieces of code called scripts or bots that will reach out in real time to various third party services to perform tasks. As an example, lets say your company has just bought an account on Salesforce to keep track of customer information. If you have a form on your website that captures who is coming, who is signing up for a free newsletter, e-book and then want to automatically register information for this person as a potential sales lead in Salesforce, you will probably use an “API call”.
An API call looks something like this “https://api.onionid.com/parameters/ID=1&APIKey=2&action=verify” . The API call begins with “https://api.onionid.com” – this is called the API endpoint, a glorified term for – who should I talk to in order to make this automated task actually work. This of it as the airline check in desk when you get to the airport and have to check in your bags. You walk up to the specific airline counter – congrats, you have just located your API endpoint!
The remainder of the API call contains parameters. These parameters tell the API endpoint what you want it to do on your behalf. In this case, we are first proving that we have the right to ask the API endpoint to perform actions on our behalf. We are using parameters like ID=1 and APIKey=2. These pieces of information, and similar, tell the API that its a valid person/ script that is making the call and hence the API endpoint will continue looking at the actions you are asking it to perform. Once the API endpoint looks up these verification parameters, then it can look at the “action” parameters like action=verify and complete the task that you have given to it. In the example above for salesforce you would have provided as an action “action=registernewlead” as an action because you want to register a new sales lead or something similar.
Where is the catch
Everything seems hunky dory doesn’t it? After all APIs help you with automation, ruling the world and all that good stuff. DevOps loves it, so does IT, so does marketing and sales and HR and everyone else. So, where is the problem?
The problem lies in the fact that it becomes extremely challenging for Security and Compliance teams to gain visibility into which API is being used, what API keys, identities are being used to what and more. This is important from a security and compliance angle since you need to know and document how your company is using third party services for PCI, SOX, SOC2, ISO, NERC CIP, NIST and more compliance standards.
You don’t think this is an issue for your company? Try this 30 second exercise – Send an email to your CISO/IT lead/Compliance lead and ask them
- Do we have a list of all third party API keys, API endpoints and people in the company who have access to these resources?
- How much visibility do we have into usage of these external APIs?
- How are we reporting on all this stuff?
The answers might leave you a bit disappointed. Take heart though, you are not alone. This is not an easy problem to solve or it would have been solved in 10 minutes by any and every IT, Security, DevOps team. For an even more concrete problem statement – Find out who in your company is using an API call to AWS/Salesforce (pick any vendor) and whether the employee actually stores the verification credentials, hard coded, in their scripts.
Most companies have these verification parameters hard coded in their scripts, bots, written on post-its and what not. This is a clear issue. If your employee gets terminated, nobody really knows where the scripts are storing these credentials, what are they doing – the beginning of panic!
Easily managing this problem
The trick is to turn security process into an enabler and not a roadblock. Even if a security process, product is bulletproof but is cumbersome to use – there will always be pushback. You will need significant higher management guidance to push through a product like this, and you won’t make many friends along the way.
To solve this problem of proliferation of API keys throughout the company, an easy, yet effective solution is required. Consider this – most companies have some sort of an employee directory. Microsoft Active Directory, LDAP, Google and more can be used as the source of who is employed with the company at this point in time. You can simply tie these identities to the API keys being used from the third party services.
How? By using an API vault – a popular choice could be Hashicorp Vault or a commercial product (like Onion ID) that helps you select who in the company needs access to a third party API and then dynamically providing their script with the verification credentials. This process helps you not create extra work for the developer, since all they have to do is make one single line of change. Instead of writing APIkey=1234 in their script, they can write APIkey=wget/curl (custom URL to your API vault) which will allow the script to get the API keys and other verification parameters in real time.
The above hits two targets simultaneously. You can now see who is using these third party API keys and make sure that employees are not storing critical verification credentials for the APIs in their scripts.