Whether it’s via a mobile, laptop or desktop, in the cloud or on the ground, APIs have become the defacto method for connecting people with data. This is great news for users: access is much smoother and often instantaneous.
But for administrators controlling sensitive data, and in particular what’s exposed to whom, access control is often a major headache. And with the implementation of APIs on the rise, this isn’t going to get any easier.
With this in mind we’ve outlined five key access control “Truths” regarding APIs – along with a little help on how to address them.
So we know that in API development there’s no crystal ball. It is possible, however, to anticipate potential scenarios. And the best way to do that is through a security risk assessment. When companies do this, most quickly realize that the risk of a data breach – due to unauthorized access – is quite high on the list of probabilities.
So how do you mitigate this risk? You can’t just sit back and wait for the attack to come: you need to be more offensive. You need to enable risk-aware access controls that go beyond perimeter protection and logging to protect business-critical data from being breached.
Do you already have a context and policy-based access control approach to APIs? Then you have most certainly ticked this problem off your list.
If not, and you’re asking yourself “Does such a solution even exist?” Read more to find out.
With a conventional API Gateway solution, a user request can be authenticated and authorized to access data based on a number of “easily” retrievable attributes, such as user roles, current location or device in use. This level of access control is sufficient for many APIs. However if you are dealing with sensitive data it will not be sufficient.
An HR manager may want to view the work-related insurance claims of an employee, but by law, cannot view any medical notes or the employee’s private medical history. Or in another scenario, a parent wanting to access their child’s bank account will have to be verified. In both of these situations, context for access control is the driver on who can see what, and when. How can these complex factors be brought into the access control equation?
If you’re familiar with ABAC, you’re probably thinking “I’ve already extended my API Gateway with context-aware authorization and boy has it made a difference.”
Or maybe you’re in this camp: “I don’t know how to solve this, but I wish you would tell me?”.
If you are the head of API development, you often have to prioritize new business over security, or visa versa. Either way, somebody is going to get on your case.
Let’s say that a Business Manager has defined a new way to monetize data – third parties want access to some of the data that is mined on your network and they are prepared to pay for it. A new API that provides them with instant access to the data needs creating and rolling out in a matter of months.
The security manager insists that all regulations (local and national) are met so that the company is compliant. The auditors expect you to be able to prove that the company is compliant and clearly show who can access what information, and under what conditions. Your job is to make it happen.
If you’ve already discovered ABAC, then you’re probably wondering what all the fuss is about.
Change management is costly and time consuming. Once an API has been released there usually isn’t much left in the budget, and developers have moved on to the next big project.
So what happens when corporate polices change? You have to juggle resources, and dedicate time that neither you nor your team have to spare. If only you could implement access control polices across all relevant APIs in one go – costs and resource requirements would be cut. Implementation would also be much quicker and security managers and auditors would be off your case. If only you had a centralized policy management solution.
If you already centrally manage policies with a XACML engine, this is one concern you don’t have to worry about. On the other hand, perhaps you’re thinking “This sounds great but how do I know if my organization is ready for a solution like this?”