In Plain Language: security between servers

Latacora is a company that helps startups build security into their products and their growing businesses. Their team recently wrote an excellent technical overview of the current state of securing, authenticating, and authorizing activity between servers. The article itself is well structured. If you’re a technical professional looking for an overview and recommendations without the details, the first few paragraphs and the final section provide the essentials.

But what about the less technical reader? Computing professionals have always had a tendency to speak the language of the priesthood among themselves. The industry jargon in Latacora’s article is hard for non-technical decision makers to parse. Let’s simplify.

Whether or not your organization uses cloud services, many of the applications you use involve a lot of server-to-server communication. An app on your desktop or other device negotiates a service (e.g., reading and sending messages, updating information, getting a report) with a server. Invisibly to you, the server works with several other servers to deliver what your app needs.

There is always some level of risk inherent in the communication between these servers. Your technical staff or service provider(s) have many tools and standards to choose among to mitigate this risk.

Commonly used solutions fall into one of these patterns:

  • in an environment where communication between the servers is highly trusted, use no security between the servers;
  • the server equivalent of passwords, where the same key is always used to verify identity and authority to request a service;
  • passwords with a limited lifetime, to reduce the risk of an eavesdropper stealing a password;
  • a password/key negotiation using encryption, making it effectively impossible to eavesdrop on a session; and
  • use a trusted third party to secure communications.

The authors’ suggested “do the simplest thing you can get away with” is a good approach. Though it would be better phrased as, “choose the simplest solution that meets the requirements.” The more complex a system is, the harder it is to configure correctly and the more prone it is to failure.

Selecting one such “simplest” security scheme for communicating between servers and using it consistently will make your systems, and by extension your business, more reliable and more secure. Standards-based choices that provide the functionality you need without adding unwanted complexity are best.

The authors are fond of Macaroons. They’re a flexible authorization system similar to the data-tracking “cookies” web browsers use. Macaroons are a mature security technology suitable for production. However, changing the security in your current systems to Macaroons may not be the best direction in your environment. Check with your technologist to determine if such a change would be desirable.

The best security technology for your organization’s server-to-server communication will depend on application support, server infrastructure, and your appetite for risk. Your senior technologist can use the details in the article from Latacora to provide a good summary of options and a well supported recommendation that will better secure your business technologies.