Explain about API Security in DevOps?
Postman performed its annual survey of developers, and as this survey and many other surveys have shown, developers are generally comfortable with the level of API security that their organization has implemented. This has been a consistent trend, with most developers being comfortable that they are protected.
The problem is most organizations also put API security and management in the hands of developers.
While API security is certainly a necessity, it is not managed in a vacuum. You really are only as secure as your weakest link, and there are a lot of links in an API-focused environment. User credentials, tokens, SSL, requesting apps and their authentication, (still) code injection concerns…The list goes on and on.
Get practical knowledge on DevOps at DevOps Online Training
I’m never comfortable with the level of API security currently implemented in DevOps environments. And I think it’s dangerous for you to be. It only takes one bad code iteration for one of the client instances to be vulnerable. That vulnerability exposes every API the client in question has access to, no matter what is being used as access control.
In the end, APIs must trust someone, or they’re useless. And that someone is most often a server app running on an instance that your users connect to. That app most often has its own credentials. How are they stored? How are they protected? What code changes could impact that instance’s security?
API gateways and management tools, when properly configured, are a big help here, but they are not a panacea. Since incoming connections must be trusted at some point, and outgoing connections must be assumed clean at some point when one of those two things is a wrong assumption, what do you have in place?
The working of API Security is shown through the following diagram
Here’s the scenario:
User A has the rights to call the ShowMeCriticalData API. This API is called from a server app running on instance B. The server app authenticates user A, then calls the API for him–either with his credentials (best case) or it's own (bad for tracking problems). If instance B receives an update that makes it vulnerable to compromise, user credentials are still needed to call ShowMeCriticalData, which is relatively secure, as long as User A is protecting their credentials adequately. However, if the app running on instance B is proxying requests and using its own credentials, Instance B becomes a weak point and attackers could use the vulnerability to call APIs without authenticating users. Worse, if User A is careless with their authentication info, there is little an organization can do to stop at least some misuse.
API logging and review can be put in place to notice odd behaviour by username and offer the early warning that a user has been compromised. But will only catch most issues.
Of course, there are smart people working on the whole array of API security threats from cross-site scripting to authentication spoofing even into TLS weaknesses. But that work is only useful if we all remember that our security could be better. With the knowledge that there are weaknesses, we can look for things to mitigate the risk. As you all know, if you have public APIs the risk will never be eliminated–the purpose of a public API is for people to use it, and that exposes it to hackers that seem to be more ingenious by the week–but minimizing the risk is worth the effort.
Being secure in your current situation means you’re not focused on making it better. With API security, particularly in the type of dynamic environment, DevOps creates, this is a dangerous road to be on. Assume there is a fatal flaw, and work to reduce vulnerabilities at each access point into the overall system.
Get more real-time explanation at DevOps Online Training India
This also goes for APIs you don’t own. We rate-limited an API that called out to Google Places to match up with our plan/budget for the project. Our app was never going to come anywhere near Google’s caps on usage, but should a portion of our infrastructure be compromised, we could potentially end up with a massive bill from Google because we called the API a zillion times in a month. Likely? Not really. Possible? Not after a few lines of rate-limiting code.
