How should *intranet* REST API calls be secured?

Question

Here's the scenario. A user outside the firewall takes a UI action in the browser. The browser makes a REST API call to system A (and is authenticated and authorized at or near the point of entry past the firewall). System A (inside the corporate network firewall) makes a REST API call to system B (also inside the corporate network firewall).

How much security is sufficient for the "internal" REST API call from system A to system B, considering that authentication and authorization already occurred at the entry point to system A?

Answer 1

Like anything else, it depends on the sensitivity of the data involved, and the level of risk vs. how much the organization wants to spend.

Usually, using strongish SSL (https connection) is considered good enough. You may need to include an authentication mechanism, if you need to audit which System A submitted the request -- for this you could use any of: client cert, HTTP Auth (basic or digest), username/password as request parameters, IP-address mapping, API keys etc.

For system->system calls, if the client system doesn't change (i.e. not a web browser or actively changing clientbase), you don't even need "real" certificates -- a strong self signed certificate is good enough, and because you distribute it to your client systems, they all know the source is valid without a 3rd party signature.

If the data are very sensitive, you might dedicate connections between the client(s) and server, either using a physically separated network, or VPN.