They say that the more things change, the more they stay the same. Nowhere is this truer than in the application...
Years ago, one of the major Achilles' heels of application security was inter-component authentication -- the mechanisms used by applications to authenticate themselves to back-end and middleware components. However, it's important to ensure that only approved components -- that is, other applications or processes -- are granted access through web APIs.
A mechanism used frequently to do this is a single, relatively static application login. As you might imagine, there are security challenges with this method.
First and foremost, the login tends to be updated infrequently. Second, it reduces the ability of the organization to monitor and log activity because all the activities are conducted under the identity of the application. As a result, those activities are grouped together under a single user ID from the point of view of back-end components.
That makes it more challenging to sort through the event information tied to a single application account, and that problem can be compounded when the application is subverted by an attacker and the credentials are stolen or otherwise compromised. If this happens, it can prove difficult to sort out which logins are legitimate application components going about their business and which logins are unauthorized.
This problem has been evident for decades, and it is still an issue in modern applications. In a RESTful API context, for example, application components still need to authenticate to each other, they just use HTTP-aware methods to do so.
For example, HTTP basic authentication or a secret value sent along in HTTP request headers are sometimes used to authenticate the remote requester of a web service. This is the case regardless of whether applications are on premises or in the cloud. Even if you use platform as a service (PaaS) or you have components in infrastructure as a service (IaaS), the question of how components interact with each other is still one that must be solved.
TLS mutual authentication
One particularly effective strategy to help add security to this process is to use TLS mutual authentication when application tiers or components interact with each other. Assuming TLS is not already in use as a mechanism for RESTful API components to communicate, enabling TLS mutual authentication -- i.e., requiring a client certificate for applications to authenticate themselves -- can be beneficial as part of your application security architecture strategy.
Essentially, you should leverage the capabilities of TLS to bolster the authentication mechanisms you employ. While TLS is not often used for web surfing -- or in any casual use of TLS from an application front-end perspective -- it does support mutual authentication between peers in a transaction.
As a user's browser validates the identity of the remote website by validating the server certificate, so too can the server validate the client in a similar fashion. In this case though, because HTTP is the transport for the API, we can enable mutual authentication between components. In fact, we can specifically limit the range of certificates acceptable to exactly what is expected by requiring a specific certificate fingerprint or serial number from a particular certificate authority. You can use this method alone or in combination with a password or static secret value, as well.
Employing a TLS mutual authentication strategy in a cloud situation does have a few dependencies. First of all, you must be able to customize the API to enable TLS mutual authentication. This means it must either be an IaaS environment -- where you can directly manipulate the configuration -- or a PaaS environment that enables this functionality. Fortunately, most of the larger PaaS players do -- Azure does, for example, as does AWS.
Advantages and disadvantages
TLS mutual authentication has a few advantages from a security standpoint. Most obviously, it means less fussing about with passwords or static secret values.
Using a password or secret brings about overhead if you're going to follow reasonable security practices; for example, changing the password periodically, monitoring its usage, enforcing complexity, making sure it is appropriately protected, etc. By using TLS mutual authentication instead, quite a bit of the extra hassle goes away. While it's a little more involved to set up initially, it reduces the amount of care and feeding required over the long term.
Another advantage is that the certificate and corresponding private key are less portable than a password. While these credentials can be stolen just like any other digital artifact, it's a little more logistically difficult to accomplish for an attacker who is seeking to impersonate a remote API caller.
From a monitoring standpoint, it is helpful as well because, by using multiple certificates, you're able to keep track of which component makes an API request with more granularity. Doing this with static passwords is possible, but it is logistically complex enough that most real-world usage tends to use the same value across multiple instances.
There are disadvantages to using TLS mutual authentication; though none of them are deal-breaking, they do require a bit of discipline in order to avoid getting burned. Most importantly, certificates expire, which means that if you generate a certificate now and load it into your application, you should be sure to remember to reissue a new certificate when the old one expires. If you forget -- and trust me, unless you plan for it, you will -- the resultant failure condition can be as catastrophic as it is difficult to ferret out and debug. It's important to keep track of certificate expiration dates and to be proactive about replacing expired certificates.
On the whole, though, using TLS mutual authentication for cloud APIs can be a productive way to bolster the security of your application processing. At a minimum, it's a useful thing for the security architect to have in their tool set as they evaluate the security of the applications they field.