Practical Cloud Considerations: Security

Lori Mac VittiePrincipal Evangelist

Compute in the cloud may be cheap but it isn't free.

The vast majority of apps today are delivered via secure HTTP. That means TLS or the increasingly frowned upon SSL. It means cryptography, which traditionally has been translated to mean performance problems.

Thanks to advances in technology, CPUs are incredibly fast today and many client (and server-side) hardware natively integrates what was once specialized cryptographic hardware. What that means is that on a per-connection basis, speed is not as much of an issue on an individual basis for cryptography as it once was.

But that doesn't mean that cryptography isn't still a source of performance and operational expense.

Most of the arguments dismissive of the argument against cryptography as a significant source of performance problems are based on simple scenarios that involve one client and one server. That's one encryption process and one decryption process. And in such scenarios, naysayers are mostly correct. The latency introduced by encryption and decryption is minimal and typically is less concerning than TCP and network-related overhead.

But applications today are not comprised of a single endpoint. There are multiple intermediaries and proxies through which a message must travel before that "single endpoint" is ever encountered. They are security and access control, load balancing and routing endpoints. Each needs to inspect the message - in the clear - in order to execute its designated role in the complex dance that is the modern data path.

Here is where the argument that cryptographic isn't as expensive starts to fall apart. On its own, a single endpoint introduces very little delay. But when repeated multiple times at each and every endpoint in the data path, those individual delays add up to something more noticeable and, particularly in the case of public cloud, operationally expensive.

Cryptography is naturally a computationally expensive process. That means it takes a lot more CPU cycles to encrypt or decrypt a message than it does to execute business logic. In the cloud, CPU cycles are analogous to money being spent. In general, it's an accepted cost because the point is to shift capital costs to operational expense.

But the costs start to add up if you are decrypting and encrypting a message multiple times. You are effectively paying for the same cryptographic process multiple times. What might be computed to cost only a penny when executed once suddenly costs five pennies when executed five times. Doing the math for the hundreds of thousands of transactions over the course of a day (or an hour) and the resulting costs are staggering.

Remember, too, that each CPU cycle consumed by cryptographic processing is a CPU cycle not spent on business logic. This means scaling out sooner than you might want to, which incurs even more costs as each additional instance is launched to handle the load.

Suffice to say that "SSL everywhere" should not result in "decrypt everywhere" architectures in the cloud.

Decrypt Once

To reduce the costs and maximize the efficacy of the CPUs you're paying for, it is worth the time to design your cloud-based architecture on a "decrypt once" principle. "Decrypt Once" means you should minimize the number of endpoints in the data path that must decrypt and re-encrypt messages in transit.

Doing that requires forethought and careful consideration of the sixteen different application services you're using to secure and scale applications today. If you aren't subject to regulations or requirements that demand end-to-end encryption, architect your data path such that messages are decrypted as early as possible to avoid additional cycles wasted on decryption later. If you are required to maintain end-to-end encryption, the combining services whenever possible will net you the most efficient use of compute resources.

Combining the services you can - say load balancing with web application firewall - on a single platform means reducing the number of times you need to decrypt messages in transit. It has the added advantage of reducing the number of connections and time on the network, too, which translates into performance benefits for users and consumers. But the real savings is in CPU cycles that aren't spent on repeated decryption and re-encryption.

It may seem a waste of time to consider the impact of encryption and decryption for an app that's lightly used today. The pennies certainly aren't covering the cost of the effort. But as apps grow and scale and live over time, those pennies are going to add up to amounts that are impactful. Not to mention that just like pennies, microseconds add up. By considering the impact of cryptography across the entire data path, you can net benefits in the long run for both users and the business.

About the Author

Lori Mac VittiePrincipal Evangelist

More blogs by Lori Mac Vittie