I was talking with the Internal Revenue Service (IRS) about their internal API strategy the week before Christmas, sharing my thoughts on the strategy that they were pitching internally when it comes to the next phase of their API journey. One topic that kept coming up is the firm line of separate between public and private APIs, which you kind of get at an organization like the IRS. It isn’t really the type of organization you want to be vague about this line, making sure everyone understands where an API should be consumed, and where it should not be consumed.
Even with that reality, I still made the suggestion that they should be treating ALL APIs like they are public. I clarified by saying you shouldn’t be getting rid of the hard line dictating whether or not an API is internal or external, but if you treat them all like they are public, and act like they are all under threat, you will be better off for it. This peaked their interest, was something they did not expect to hear from me, and was something they would be adding to their recommendations for the next version of their API strategy.
The first benefit of treating your internal APIs like they are public is when it come to security, logging, and overall API management. You have the tools in place to catch any threats, and develop awareness regarding how an API is being used, both good and bad. While the threats might be minimized internally, developing the same awareness, and having the tools to identify who is using what, and respond accordingly will benefit operations. API security isn’t just about firewalls, it is about an awareness of who is using what.
The next benefit is about the future of your APIs. If you treat APIs like they are public, and you ever want to make it public, you will be in much better shape. You will have proper authentication, management, logging, and security controls already in place. You can cross the line between internal and external with much less friction. When you are ready to work with partners on a project, the time to make resources available can be significantly reduced, making things more efficient and agile when it comes to working with partners.
I get the hard line between internal and external. However I don’t get having two separate API strategies. Have one strategy. Treat everything like they are public, but then be very strict, and explicit about who has access to an API, and monitor, audit, analyze, and report on who has access to API resources in real time. These are web APIs. Let’s treat them all the same, and expect that there will be threats and misuse of varying degrees. Let’s treat all APIs equal, and reduce the chance people will become complacent with API management and security just because it is an “internal” API.
